Info

You are currently browsing the archives for the security category.

March 2010
M T W T F S S
« Feb    
1234567
891011121314
15161718192021
22232425262728
293031  
Links

Archive for the security Category

2010 CWE/SANS Top 25 Most Dangerous Programming Errors

The 2010 CWE (Common Weakness Enumeration) / SANS Top 25 Most Dangerous Programming Errors has been released. The full report should be required reading for all web programmers and testers. A pdf version is also available.

Here are the 25 items:

  1. Failure to Preserve Web Page Structure (’Cross-site Scripting’)
  2. Improper Sanitization of Special Elements used in an SQL Command (’SQL Injection’)
  3. Buffer Copy without Checking Size of Input (’Classic Buffer Overflow’)
  4. Cross-Site Request Forgery (CSRF)
  5. Improper Access Control (Authorization)
  6. Reliance on Untrusted Inputs in a Security Decision
  7. Improper Limitation of a Pathname to a Restricted Directory (’Path Traversal’)
  8. Unrestricted Upload of File with Dangerous Type
  9. Improper Sanitization of Special Elements used in an OS Command (’OS Command Injection’)
  10. Missing Encryption of Sensitive Data
  11. Use of Hard-coded Credentials
  12. Buffer Access with Incorrect Length Value
  13. Improper Control of Filename for Include/Require Statement in PHP Program (’PHP File Inclusion’)
  14. Improper Validation of Array Index
  15. Improper Check for Unusual or Exceptional Conditions
  16. Information Exposure Through an Error Message
  17. Integer Overflow or Wraparound
  18. Incorrect Calculation of Buffer Size
  19. Missing Authentication for Critical Function
  20. Download of Code Without Integrity Check
  21. Incorrect Permission Assignment for Critical Resource
  22. Allocation of Resources Without Limits or Throttling
  23. URL Redirection to Untrusted Site (’Open Redirect’)
  24. Use of a Broken or Risky Cryptographic Algorithm
  25. Race Condition

 

How to Verify that HTTP TRACE is Disabled - Telnet Disabled

In a prior post, I described how to use telnet to verify that the HTTP TRACE command is disabled. A commenter asked:

What if telnet is actively being blocked… is there another way to invoke the TRACE request in an attempt to verify whether the potential vulnerability exists?

My immediate reaction was that I needed to research how to do this. What a fool I am…

The fact of the matter is that if an HTTP connection is able to connect to the server than the method I described will still work. Because we are using telnet to impersonate a browser - connecting via port 80 - even if telnet is blocked (usually port 23), using telnet via port 80 will still work. If the browser can connect via this way, so can telnet via port 80.

 

How to Verify that HTTP TRACE is Disabled

In the past, the TRACE command in the HTTP specification was considered a “safe” command. However, due to the information disclosed combined with other cross-domain exploits, TRACE is no longer considered safe. See US-CERT Vulnerability Note VU#867593 for more information.

I was asked how to verify that the TRACE command (in Apache) is disabled. The easiest way to do this is to use telnet. Launch telnet.

telnet hostname 80

Now, we can issue the TRACE command for a given url.

TRACE /index.html HTTP/1.0



If TRACE is enabled, you will get output that looks something like this:

HTTP/1.1 200 OK
Date: Fri, 05 Dec 2008 05:59:45 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.3 with Suhosin-Patch
Connection: close
Content-Type: message/http

TRACE /index.html HTTP/1.0

Connection closed by foreign host.

Now, if TRACE is disabled, the output will look like this:


HTTP/1.1 405 Method Not Allowed
Date: Mon, 08 Dec 2008 21:26:13 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.4 with Suhosin-Patch
Allow:
Content-Length: 347
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for the URL /index.html.</p>
<hr>
<address>Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.4 with Suhosin-Patch Server at localhost Port 80</address>
</body></html>
Connection closed by foreign host.

 

Using Humor to Explain SQL Injection

I have explained the concepts behind SQL injection dozens of times. I think I will start using the following comic as a starting point: xkcd - A webcomic of romance, sarcasm, math, and language - By Randall Munroe.

 

Web Security Testing Links

I recently completed an overview of web security testing for my team. Below are the links I used as resources. I consider the OWASP Testing Guide to be the most useful.

Payment Card Industry Security Standards
PCI Security Standards Council - https://www.pcisecuritystandards.org/
PCI Data Security Standard - https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

Open Web Application Security Project (OWASP)
OWASP Main Site - http://www.owasp.org
OWASP Top 10 (2007) Web Application Vulnerabilities - http://www.owasp.org/index.php/Top_10_2007
OWASP Testing Guide (v2) - http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents

SANS Institute (SANS stands for SysAdmin, Audit, Network, Security)
SANS Main Site - http://www.sans.org
SANS Top-20 Internet Security Attach Targets - http://www.sans.org

United States Computer Emergency Readiness Team (US-CERT)
US-CERT Main Site - http://www.us-cert.gov/
US-CERT Security Alerts (Technical) - http://www.us-cert.gov/cas/techalerts/
US-CERT Security Bulletins - http://www.us-cert.gov/cas/bulletins/

Vendor Sites and Resources
SPI Dynamics - http://www.spidynamics.com/
     
White Papers - http://www.spidynamics.com/spilabs/education/whitepapers.html

     
Cross Site Scripting White Paper - http://www.spidynamics.com/assets/documents/SPIcross-sitescripting.pdf

     
SQL Injection White Paper - http://www.spidynamics.com/assets/documents/WhitepaperSQLInjection.pdf

Fortify Software - http://www.fortifysoftware.com/
     
Fortify Taxonomy: Software Security Errors - http://www.fortifysoftware.com/vulncat/

 

Web Site Security Testing - Quick List of Things to Check

I am on the lookout for resources that will help my team with security testing. Usually, security is not an items that is considered up front when planning the testing of an application. A project I am working on now was built from the ground up — so it did not / could not rely on the security infrastructure in place in existing applications. I went looking for a list of items to check and came across the Open Web Application Security Project (OWASP) site.

OWASP has a Top Ten project which is a list of what they consider the most critical web security flaws. It appears that it is updated on a yearly basis. There is a lot of detail available, but for a quick list of things to check in a web application, this page is the place to begin.

The 2006 OWASP Top Ten list of critical web security flaws is:

  1. Unvalidated Input
  2. Broken Access Control
  3. Broken Authentication and Session Management
  4. Cross Site Scripting
  5. Buffer Overflow
  6. Injection Flaws
  7. Improper Error Handling
  8. Insecure Storage
  9. Application Denial of Service
  10. Insecure Configuration Management

 

Web Site Security Testing - Directory Listing

One of the projects I am working on is running in a new httpserver instance. One of the things that I have discovered is that many of the things that we put in place regarding web site security need to be recreated in this new application.

As a matter of course, I went to check if it was possible to get a directory listing of the images directory. I was able to do so. Looking at the structure of the site, I was able to get directory listing of all subdirectories in the site. I needed to discuss with the developers why this is not a good idea. Tonight, I came across the following link that describes why this is a threat: [Directory Indexing] Threat Classification - Web Application Security Consortium

 

Trustworthy Software Systems

I attended a great lecture by Professor Larry Bernstein of the Stevens Institute of Technology. More on Professor Bernstein can be found at his site.

The topic of the presentation was “Trustworthy Software Systems”. Professor Bernstein is a great speaker and shows genuine enthusiasm for his work. He defines trustworthy software as being safe, reliable and secure. On one slide, he defines these terms as:

  • safe - does no harm
  • reliable - no crashes or unexpected behavior
  • secure - no hacking possible
  • He points out that the requirements which make a system trustworthy are non-functional.

    He referred the audience several time to “Trustworthy Systems Through Quantitative Software Engineering ” by Larry Bernstein and C. M. Yuhas. I am planning on becoming more familiar with his work in this area.

     

    Test Values: String (Format String)

    In a prior post, I described various values I use to test strings. However, there are some special characters which may result in unexpected behavior or security vulnerabilities when they are encountered within a string that is later displayed in the application. The specifics of how these works depends on the capabilities of the programming language - so research how strings may be formatted for output in the language used to develop your application. A recent article that describes this well is Programming Language Format String Vulnerabilities” by Hal Burch and Robert C. Seacord. printf style formatting strings are ripe for these types of errors.

    Special character values:

    “\\” Backslash related strings
    “Backslash\\Backslash”
    “\a” Alert (bell) related strings
    “Bell\aBell
    “\b” Backspace related strings
    “Backspace\bBackspace”
    “\f” Form feed related strings
    “Form Feed\fForm Feed”
    “\n” Newline related strings
    “Newline\nNewline”
    “\r” Carriage return related strings
    “Carriage Return\rCarriage Return”
    “\t” Tab related strings
    “Tab\tTab”
    “\v” Vertical tab related strings
    “Vertical Tab\vVertical Tab”

    Format value strings:

    “Decimal: %d” Signed decimal
    “Decimal: %i” Signed decimal
    “Octal: %o” Unsigned octal
    “Decimal: %u” Unsigned decimal
    “Hex: %x” Unsigned hex
    “Hex: %X” Unsigned hex
    “Floating: %.5f” Floating point
    “Exponential: %.5e” Exponential
    “Exponential: %.5E” Exponential
    “Unsigned Char: %c” Character (converted from integer value)
    “String: %s” String

     

    Web Login and Authentication - OpenID

    One of the challenges I have is keeping up with all of the developments and new technologies that are not the ones I use on a daily basis. I had seen references to OpenID but had not spent anytime researching it. Luckily, Scott Hanselman covered OpenID in a recent Hanselminutes. Scott describes OpenID and how it is used to allow someone to login into a web site and provide that website with selected information.

    I decided to play around with OpenID myself. First, I created an account on MyOpenID, a free OpenID server. When you create an account, you are assigned a URL that you can then use to login to sites that support OpenID. In my case, the URL is “http://mensming.myopenid.com”. I also created 2 personas - sets of information I can choose to reveal to a site. I created a minimal persona as the default and a fully populated persona which I named “full”.

    Once I had my account set up, I wanted to try it out. MyOpenID includes a directory of sites that support OpenID. I chose Stikis which is a web based sticky note site. I put my OpenID URL into the appropriate login box, mensming.myopenid.com, and clicked on the login button. I was redirected to the MyOpenID site where I was prompted for my password. After successfully logging in, I was presented with a screen informing me that stikis.com was requesting my nickname (required) and my email address (optional). I had the option to select a different persona and decide what to reveal. I also had the choice “Allow Forever”, “Allow Once” or “Deny”. Once I made my choice (”Allow Once”), I was redirected back to the site and was logged in.

    However, I really don’t want my ID to be this URL assigned to me by MyOpenID. I would really like to be able to use my own URL. There are 2 ways to do this. One is to install an OpenID server at your URL. (I really don’t want to do that…) The other is to add some items to the HTML header on the home page of the URL. I added the following to the HEAD section of the home page at meesqa.com.


    <link rel="openid.server" href="http://www.myopenid.com/server" />
    <link rel=”openid.delegate” href=”http://mensming.myopenid.com/” />
    <meta http-equiv=”X-XRDS-Location”
       content=”http://mensming.myopenid.com/xrds” />

    With this in place, I can now use meesqa.com as my OpenID. (Note: In the HEAD section of http://mensming.myopenid.com/, you only see the openid.server setting.)

    Why is this in a blog dedicated to software testing? I think it is important to understand how emerging technologies (which may or may not be accepted) work and become familiar with them before we need to test a product with them. If I were testing a site that used OpenID, I would make sure I verified:

  • OpenID URL that points to an OpenID provider
  • OpenID URL that uses the openid.delegate header
  •  
    As well as the various persona options and error conditions that may arise when communicating to a system outside of the one being tested.

     

    |