Archive for the security Category

How to Verify that HTTP TRACE is Disabled

December 8, 2008 by mensming.

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.

 

Posted in security, web testing | No Comments »

Using Humor to Explain SQL Injection

October 15, 2007 by mensming.

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.

 

Posted in training, security | No Comments »

Web Security Testing Links

June 13, 2007 by mensming.

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/

 

Posted in security, web testing | No Comments »

Web Site Security Testing - Quick List of Things to Check

April 9, 2007 by mensming.

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

 

Posted in security, web testing | No Comments »

Web Site Security Testing - Directory Listing

April 4, 2007 by mensming.

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

 

Posted in security, web testing | No Comments »

Trustworthy Software Systems

February 24, 2007 by mensming.

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.

     

    Posted in security, system testing, web testing | No Comments »

    Test Values: String (Format String)

    February 21, 2007 by mensming.

    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

     

    Posted in security, system testing, web testing | No Comments »

    Web Login and Authentication - OpenID

    February 19, 2007 by mensming.

    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.

     

    Posted in security, web testing | No Comments »

    |