parsonsisconsulting

Parsons Software Security Consulting Blog

Parsons Software Security Consulting has new website and is offering new services

leave a comment »

My company Parsons Software Security Consulting, LLC has a new look feel and logo. We also have a new website and are offering a new suite of services. The new logo can be found here.

As far as the new web site it can be found here. http://www.parsonsisconsulting.com.

For new services we are going to offer secure website development and social media advertising. Stay tuned for Parsons Stark Marketing.

Written by mparsons1980

March 28, 2011 at 6:21 am

Posted in Uncategorized

How many software security bugs can you find in OWASP web goat below?

leave a comment »

Today’s post is going to be interactive.  I am going to show the source code of a file in web goat.    The file name is BlindSQLInjection.java.   I am asking my readers to point out the security vulnerabilities in the code and post below in comments.  I will post my answers in a couple days.

Many thanks to OWASP, Jeff Williams, Aspect Security and Bruce Mayhew and anyone else that have worked on the web goat project.


package org.owasp.webgoat.lessons;

import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.<a class="zem_slink" title="Dynamic array" rel="wikipedia" href="http://en.wikipedia.org/wiki/Dynamic_array">ArrayList</a>;
import java.util.List;
import org.apache.ecs.Element;
import org.apache.ecs.ElementContainer;
import org.apache.ecs.StringElement;
import org.apache.ecs.html.Input;
import org.apache.ecs.html.P;
import org.owasp.webgoat.session.DatabaseUtilities;
import org.owasp.webgoat.session.ECSFactory;
import org.owasp.webgoat.session.WebSession;

/***************************************************************************************************
 *
 *
 * This file is part of WebGoat, an <a class="zem_slink" title="OWASP" rel="wikipedia" href="http://en.wikipedia.org/wiki/OWASP">Open Web Application Security Project</a> utility. For details,
 * please see http://www.owasp.org/
 *
 * Copyright (c) 2002 - 2007 Bruce Mayhew
 *
 * This program is free software; you can redistribute it and/or modify it under the terms of the
 * <a class="zem_slink" title="GNU General Public License" rel="wikipedia" href="http://en.wikipedia.org/wiki/GNU_General_Public_License">GNU General Public License</a> as published by the Free Software Foundation; either version 2 of the
 * License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
 * even the <a class="zem_slink" title="Implied warranty" rel="wikipedia" href="http://en.wikipedia.org/wiki/Implied_warranty">implied warranty of MERCHANTABILITY</a> or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License along with this program; if
 * not, write to the <a class="zem_slink" title="Free Software Foundation" rel="homepage" href="http://www.fsf.org/">Free Software Foundation, Inc.</a>, 59 Temple Place - Suite 330, Boston, MA
 * 02111-1307, USA.
 *
 * Getting Source ==============
 *
 * Source for this application is maintained at code.google.com, a repository for free software
 * projects.
 *
 * For details, please see http://code.google.com/p/webgoat/
 *
 * @author Chuck Willis <a href="http://www.securityfoundry.com">Chuck's web site</a> (this lesson
 *         is heavily based on Bruce Mayhews' <a class="zem_slink" title="SQL" rel="wikipedia" href="http://en.wikipedia.org/wiki/SQL">SQL</a> Injection lesson
 * @created January 14, 2005
 */
public class BlindSqlInjection extends LessonAdapter
{

 private final static String ACCT_NUM = "account_number";

 private final static int TARGET_ACCT_NUM = 15613;

 /**
 * Description of the Method
 *
 * @param s
 *            Description of the Parameter
 * @return Description of the <a class="zem_slink" title="Return statement" rel="wikipedia" href="http://en.wikipedia.org/wiki/Return_statement">Return Value</a>
 */
 protected Element createContent(WebSession s)
 {
 ElementContainer ec = new ElementContainer();

 try
 {
 Connection connection = DatabaseUtilities.getConnection(s);

 ec.addElement(new P().addElement("Enter your Account Number: "));

 String accountNumber = s.getParser().getRawParameter(ACCT_NUM, "101");
 Input input = new Input(Input.TEXT, ACCT_NUM, accountNumber.toString());
 ec.addElement(input);

 Element b = ECSFactory.makeButton("Go!");
 ec.addElement(b);

 String query = "<a class="zem_slink" title="Select (SQL)" rel="wikipedia" href="http://en.wikipedia.org/wiki/Select_%28SQL%29">SELECT</a> * FROM user_data WHERE userid = " + accountNumber;
 String answer_query;
 answer_query = "SELECT TOP 1 first_name FROM user_data WHERE userid = " + TARGET_ACCT_NUM;

 try
 {
 Statement answer_statement = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
 ResultSet.CONCUR_READ_ONLY);
 ResultSet answer_results = answer_statement.executeQuery(answer_query);
 answer_results.first();
 //System.out.println("Account: " + accountNumber);
 //System.out.println("Answer : " + answer_results.getString(1));
 if (accountNumber.toString().equals(answer_results.getString(1)))
 {
 makeSuccess(s);
 }
 else
 {

 Statement statement = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
 ResultSet.CONCUR_READ_ONLY);
 ResultSet results = statement.executeQuery(query);

 if ((results != null) && (results.first() == true))
 {
 ec.addElement(new P().addElement("<a class="zem_slink" title="National identification number" rel="wikipedia" href="http://en.wikipedia.org/wiki/National_identification_number">Account number</a> is valid"));
 }
 else
 {
 ec.addElement(new P().addElement("Invalid account number"));
 }
 }
 } catch (SQLException sqle)
 {
 ec.addElement(new P().addElement("An error occurred, please try again."));
 }
 } catch (Exception e)
 {
 s.setMessage("Error generating " + this.getClass().getName());
 e.printStackTrace();
 }

 return (ec);
 }

 /**
 * Gets the category attribute of the SqlInjection object
 *
 * @return The category value
 */
 protected Category getDefaultCategory()
 {
 return Category.INJECTION;
 }

 /**
 * Gets the credits attribute of the AbstractLesson object
 *
 * @return The credits value
 */
 public Element getCredits()
 {
 return new StringElement("By Chuck Willis");
 }

 /**
 * Gets the hints attribute of the DatabaseFieldScreen object
 *
 * @return The hints value
 */
 protected List<String> getHints(WebSession s)
 {
 List<String> hints = new ArrayList<String>();
 hints.add("Compound SQL statements can be made by joining multiple tests with keywords like AND and OR. "
 + "Create a SQL statement that you can use as a true/false test and then "
 + "select the first character of the target element and do a start narrowing "
 + "down the character using > and <"
 + "<br><br>The backend database is HSQLDB.  Keep that in mind if you research SQL functions "
 + "on the Internet since different databases use some different functions and syntax.");
 hints.add("This is the code for the query being built and issued by WebGoat:<br><br> "
 + "\"SELECT * FROM user_data WHERE userid = \" + accountNumber ");
 hints.add("The application is taking your input and inserting it at the end of a pre-formed SQL command. "
 + "You will need to make use of the following SQL functions: "
 + "<br><br>SELECT - query for your target data and get a string "
 + "<br><br>substr(string, start, length) - returns a "
 + "substring of string starting at the start character and going for length characters "
 + "<br><br>ascii(string) will return the ascii value of the first character in string "
 + "<br><br>&gt and &lt - once you have a character's value, compare it to a choosen one");
 hints.add("Example: is the first character of the first_name of userid " + TARGET_ACCT_NUM
 + " less than 'M' (ascii 77)? "
 + "<br><br>101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=" + TARGET_ACCT_NUM
 + ") , 1 , 1) ) < 77 ); "
 + "<br><br>If you get back that account number is valid, then yes.  If get back that the number is"
 + "invalid then answer is no.");
 hints.add("Another example: is the second character of the first_name of userid "
 + TARGET_ACCT_NUM
 + " greater than 'm' (ascii 109)? "
 + "<br><br>101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid="
 + TARGET_ACCT_NUM
 + ") , 2 , 1) ) > 109 ); "
 + "<br><br>If you get back that account number is valid, then yes.  If get back that the number is "
 + "invalid then answer is no.");
 return hints;
 }

 /**
 * Gets the instructions attribute of the SqlInjection object
 *
 * @return The instructions value
 */
 public String getInstructions(WebSession s)
 {
 String instructions = "The form below allows a user to enter an account number and determine if "
 + "it is valid or not.  Use this form to develop a true / false test check other entries in the database.  "
 + "<br><br>Reference Ascii Values: 'A' = 65   'Z' = 90   'a' = 97   'z' = 122 "
 + "<br><br>The goal is to find the value of " + "the first_name in table user_data for userid "
 + TARGET_ACCT_NUM
 + ".  Put the discovered name in the form to pass the lesson.  Only the discovered name "
 + "should be put into the form field, paying close attention to the spelling and capitalization.";

 return (instructions);
 }

 private final static Integer DEFAULT_RANKING = new Integer(70);

 protected Integer getDefaultRanking()
 {
 return DEFAULT_RANKING;
 }

 /**
 * Gets the title attribute of the DatabaseFieldScreen object
 *
 * @return The title value
 */
 public String getTitle()
 {
 return ("Blind SQL Injection");
 }

 /**
 * Constructor for the DatabaseFieldScreen object
 *
 * @param s
 *            Description of the Parameter
 */
 public void handleRequest(WebSession s)
 {
 try
 {
 super.handleRequest(s);
 } catch (Exception e)
 {
 //System.out.println("Exception caught: " + e);
 e.printStackTrace(System.out);
 }
 }
}

 

Matt Parsons, CISSP, MSM

mparsons1980@gmail.com

Parsons Software Security Consulting, LLC

Threat Model for OWASP web goat

leave a comment »

I am trying to completely dissect OWASP’s web goat and link source code findings with web penetration findings.   In my quest to do this I have created a very, very rough threat model.   There is a lot more that needs to be added to the threat model.   I have completed probably ten threat models for different clients’ of mine.   I used the Microsoft Threat Model tool. I used an older version.  I think there are newer ones and better ones.   It is a good idea to use a threat model to see all of the components of the application.   It allows a security analyst or a developer to see the users’ of the application, the data and the possible data exposure of the data of the confidentiality, integrity and availibility of your application.    You can then create use and abuse cases for the application.

 

 

 

 

 

 

 

 

Matt Parsons, CISSP, MSM

mparsons1980@gmail.com

Parsons Software Security Consulting, LLC

Reflected Cross Site Scripting in OWASP Web Goat source code

leave a comment »

I am doing another web goat vulnerability.  This time once again I scanned Web Goat with a commercial static code analyzer.   The tool is telling me that the below vulnerability is reflected cross site scripting.    With reflected XSS attacks an attacker tricks a user into sending malicious code to a vulnerable web server.   This could access the user’s cookie.


Description of the Exception

*/

public String getRawParameter(String name) throws ParameterNotFoundException

{

String[] values = request.getParameterValues(name);

if (values == null)

{

throw new ParameterNotFoundException(name + " not found");

}

else if (values[0].length() == 0) { throw new ParameterNotFoundException(name + " was empty"); }

return (values[0]);


public String getRawParameter(String name, String def)

{

try

{

return getRawParameter(name);

} catch (Exception e)

{

return def;

}

}

/**

* Gets the rawParameter attribute of the ParameterParser object

*

String to = s.getParser().getRawParameter(HIDDEN_TO, "");

String gId = s.getParser().getRawParameter(GMAIL_ID, "");

String gPass = s.getParser().getRawParameter(GMAIL_PASS, "");

String message = s.getParser().getRawParameter(MESSAGE, "");

String subject = s.getParser().getRawParameter(SUBJECT, "");

boolean haveCredentials = !(YOUR_REAL_GMAIL_ID.equals(gId) || YOUR_REAL_GMAIL_PASSWORD.equals(gPass));

ec.addElement(new HR());

createGoogleCredentials(s, ec);

ec.addElement(new HR());

ec.addElement(new BR());

createMailMessage(s, subject, message, ec);

{

if (haveCredentials)

{

Message sentMessage = sendGoogleMail(to, subject, message, emailFromAddress, gId, gPass);

formatMail(ec, sentMessage);

}

else

{

sendSimulatedMail(ec, to, subject, message);

}

}

From reading the code it looks like it gets your gmail information and then sends the message without validating any inputs or encoding any outputs.

All of this takes place inside of the Web Goat file uncheckedemail.java.

Once again thanks to OWASP and Aspect Security for creating and supporting web goat.  It’s a great web application security to practice white box ethical hacking, secure code review without going to prison for real hacking.


msg.setRecipients(Message.RecipientType.TO, addressTo);

// Setting the Subject and Content Type

msg.setSubject(subject);

msg.setContent(message, "text/plain");

Transport.send(msg);

return msg;
<pre>

I couldn't find the page in Web goat that the above code references, but I was able to find the reflected XSS lesson in web goat.
I went to the recently retired from software security blogging, RSNAKE's hackers.org website.

I used the following script to attack it.   
 
<IMG SRC=`javascript:alert("Parsons Software Security Consulting says, 'XSS'")`>


Matt Parsons, CISSP, MSM
Parsons Software Security Consulting, LLC
mparsons1980@gmail.com

Parsons Software Security Consulting, LLC Video Introduction

leave a comment »

OWASP web goat source code SQL injection code vulnerability

with 3 comments

For this post, I have to give credit to OWASP for creating web goat.   I scanned the vulnerable application with different commercial static code analysis analyzers which allow the user to see the code behind the vulnerabilities.


public String getRawParameter(String name) throws ParameterNotFoundException

{

String[] values = request.getParameterValues(name);

if (values == null)

{

throw new ParameterNotFoundException(name + " not found");

}

else if (values[0].length() == 0) { throw new ParameterNotFoundException(name + " was empty"); }

return (values[0]);

Notice that there is not a validation mechanism for the values USERNAME and PASSWORD.


try

{

String username = "";

String password = "";

username = s.getParser().getRawParameter(USERNAME);

password = s.getParser().getRawParameter(PASSWORD);


// If they get back more than one user they succeeded

if (results.getRow() >= 1)

{

// Make sure this isn't data from an sql injected query.

if (results.getString(2).equals(username) && results.getString(3).equals(password))

{

String insertData1 = "INSERT INTO user_login VALUES ( '" + username + "', '"

+ s.getUserName() + "' )";

statement.executeUpdate(insertData1);

}

// check the total count of logins

query = "SELECT * FROM user_login WHERE webgoat_user = '" + s.getUserName() + "'";

results = statement.executeQuery(query);

results.last();

// If they get back more than one user they succeeded

if (results.getRow() >= 3)

{

makeSuccess(s);

Above is the visual smart trace of the SQL injection code so you can visually see it and understand it.   The red boxes are sources and sinks.  The blue boxes are sinks as well.   The grey boxes allow code to pass through them.  The grey boxes should have validation mechanisms in them.   Those grey boxes don’t and this allows for SQL injection.   Webgoat by design, is also using dynamic SQL statements and not parameterized queries which allow for SQL injection that it teaches on the front end of the lessson.

Here are the screen shots of the application which is vulnerable to SQL injection.   Thanks for Aspect Security for creating this application.

My passion is software security and linking web penetration testing with source code analysis.

Matt Parsons, CISSP, MSM, mparsons1980@gmail.com

Parsons Software Security Consulting, LLC

How to find Robots.txt with 02

with 2 comments

We already discussed a script to find the crossdomain.xml file with 02.  Today we are going to talk about how to find the Robots.txt file.  Many websites have Robots.txt file but sometimes they contain sensitive information inside of these files.   Today we are going to write a script that searches Google for these files.

 

 

Below is a sample Robots.txt from a sample web application.

 

 

 

 

 

 


var ie = panel.clear().add_IE().silent(true);
ie.open("http://www.google.com");
ie.field("Search").value("inurl:robots.txt filetype:txt");


ie.button("Google Search").click();
var targetUrls = new List<string>();

foreach(var link in ie.links().urls())
 if (link.ends("robots.txt"))
 targetUrls.Add(link);

return targetUrls;
return targetUrls;
return targetUrls;
return ie.buttons();

//O2File:WatiN_IE_ExtensionMethods.cs
//using  O2.XRules.Database.Utils.O2
//O2Ref:WatiN.Core.1x.dll

 

 

 

 

I don’t plan on showing you how to exploit robots.txt.  But the 02 script is a simple one to find robots.txt  out in the wild.

 

Parsons Software Security Consulting, LLC

Securing the Internet one Application at a time.

 

mparsons [at] gmail.com

 

Written by mparsons1980

December 8, 2010 at 11:07 pm

Etherpad 02 scripting to search and click on a link in Google

leave a comment »

I was on an Etherpad session with Dinis and Sarah from OWASP.   Below is the link to Etherpad.   Etherpad is a great tool for programmers and for us to help write scripts together and trouble shoot.

http://ietherpad.com/

We used the free version.

Below are our Etherpad sessions from December, 3, 2010.

http://ietherpad.com/xkckfhJGAY

http://ietherpad.com/UYmog5ljkj

Dinis blogs about it on his blog.   http://o2platform.wordpress.com/2010/12/04/o2-script-to-perform-a-google-search/

Below is today’s 02 script.  Dinis is the original author but I tweaked it to do some shameless self promoting.


panel.clear();
var ie = panel.add_IE().silent(true);
ie.disableFlashing(); // use this when developing the script to make it faster
Action<string> searchGoogle =
 (searchText)=> {
 ie.open("http://www.google.com");
 searchText = searchText.line();       // here......  <----
 ie.field("Search").value(searchText).flash();
 ie.button("Google Search").Click();
 };
Action<string> clickOnLink =
 (linkToClick)=> {
 if (ie.hasLink(linkToClick))
 ie.link(linkToClick).flash().click();
 else
 "Error: could not find link: {0}".error(linkToClick);
 };

searchGoogle("Parsons Software Security Consulting, LLC");
clickOnLink("Parsons Software Security Consulting, LLC - Home");


return ie.link("Parsons Software Security Consulting, LLC - Home").click();




//O2File:WatiN_IE_ExtensionMethods.cs
//using O2.XRules.Database.Utils.O2
//O2Ref:WatiN.Core.1x.dll


This code opens Google.  Disables flashing to make the search faster.  Then searches for my company, Parsons Software Security Consulting, LLC and clicks on the first link then opening my company’s website.

There is the script. Feel free to email me at mparsons1980@gmail.com for comments.

Matt Parsons, CISSP, MSM,
Parsons Software Security Consulting, LLC
Securing the Internet one Application at a time.

Written by mparsons1980

December 4, 2010 at 4:05 am

How to find Crossdomain.xml Cross Site Request Forgery with 02

with one comment

Lately it seems that a lot of people are talking about the potential security vulnerabilities of having an unrestricted crossdomain.xml.   It’s public knowledge that this can be abused by an attacker setting up Cross Site Request Forgery.

Below is the sample code in the crossdomain.xml.   This is a simple one.  Some of the big websites that have these crossdomain.xml’s unrestricted have alot more data in the xml file.   From the blogs that I have read in the community and from HP Web Inspect Remediation Guide “Exploiting a Vulnerability Involves crafting a custom Flash Application”.


<cross-domain-policy>

<site-control permitted-cross-domain-policies="all"/>

<allow-access-from domain="*"/>

</cross-domain-policy>

The fix is “not to design and deploy Flash APIS meant to be accessible to arbitrary third parties.   It is also recommended “to host these on a sub domain”. We are not going to discuss how to exploit this vulnerability but rather to find it in the wild with 02.

So lets open up 02.   I like using Dinis Cruz’s version because it is more powerful.

Then lets open IE Automation.

Below is the default script in IE Automation that Dinis Created.  The default website is Google.


panel.clear();
var ie = panel.add_IE().silent(true);

ie.open("http://www.google.com");

//O2File:WatiN_IE_ExtensionMethods.cs
//using O2.XRules.Database.Utils.O2
//O2Ref:WatiN.Core.1x.dll


var topPanel = panel.<strong>clear</strong>().<strong>add_Panel</strong>();
var ie = topPanel.<strong>add_IE</strong>().<strong>silent</strong>(<strong>true</strong>);
ie.<strong>open</strong>("http://www.google.com");
ie.<strong>field</strong>("Search").<strong>value</strong>("inurl:crossdomain.xml filetype:xml");
ie.<strong>button</strong>("Google Search").<strong>click</strong>();
var targetUrls = <strong>new </strong>List<string>();
<strong>foreach</strong>(var link <strong>in </strong>ie.<strong>links</strong>().<strong>urls</strong>())
<strong>if </strong>(link.<strong>ends</strong>("crossdomain.xml"))
targetUrls.<strong>Add</strong>(link);
var listOfUrls = topPanel.insert_Left<Panel>(250).<strong>add_TextArea</strong>().<strong>wordWrap</strong>(<strong>false</strong>);
listOfUrls.<strong>set_Text</strong>(targetUrls.<strong>str</strong>());
return targetUrls;

//O2File:WatiN_IE_ExtensionMethods.cs
//using  O2.XRules.Database.Utils.O2
//O2Ref:WatiN.Core.1x.dll

var topPanel = panel.clear().add_Panel();
var ie = topPanel.add_IE().silent(true);
ie.open("http://www.google.com");
ie.field("Search").value("inurl:crossdomain.xml filetype:xml");
ie.button("Google Search").click();

var listOfUrls = topPanel.insert_Left<Panel>(350).add_TreeView();
var fileContents =listOfUrls.insert_Below<Panel>(200).add_SourceCodeViewer();

listOfUrls.afterSelect<string>(
 (selectedUrl)=> {
 listOfUrls.backColor(Color.LightPink);
 Application.DoEvents();
 var html = selectedUrl.uri().getHtml();
 fileContents.set_Text(html);
 listOfUrls.backColor(Color.White);
 });

foreach(var link in ie.links().urls())
 if (link.ends("crossdomain.xml"))
 listOfUrls.add_Node(link,link);

listOfUrls.selectFirst();

//O2File:WatiN_IE_ExtensionMethods.cs
//using  O2.XRules.Database.Utils.O2
//O2Ref:WatiN.Core.1x.dll

If the script executes properly it displays all the potential websites that are vulnerable to this vulnerability and then puts them inside of 02.  In order for them to be vulnerable allow-access-from-domain has to be set to *.    I don’t want to expose which sites are vulnerable due to legal reasons.   What is missing from the script is  is the rule that checks for the * value.

Many thanks to Dinis, all the security researchers that have been blogging about this vulnerability, HP, IBM and the Netsparker crew.

http://erlend.oftedal.no/blog/?blogid=107

http://shiflett.org/blog/2006/sep/the-dangers-of-cross-domain-ajax-with-flash

http://www.hp.com/go/appsec

www.ibm.com/software/awdtools/appscan/

http://www.o2platform.com/wiki/Main_Page

http://diniscruz.blogspot.com/

http://www.mavitunasecurity.com/

Matt Parsons, CISSP, MSM

mparsons [at]  gmail.com

Parsons Software Security Consulting, LLC Securing the Internet one Application at a time.

Written by mparsons1980

December 2, 2010 at 7:40 pm

Sample Software Security Report for IBM test fire application

leave a comment »

Web Application Assessment

for IBM demo Test Fire Website

http://demo.testfire.net/

Parsons Software Security Consulting, LLC

http://www.parsonsisconsulting.com/

http://www.parsonsisconsultingblog.com/

 

 

 

November 22, 2010

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Executive Summary

 

Web Application Assessment Overview

Parsons Software Security Consulting, LLC performed the Web Application Assessment for IBM  Test Fire in November of 2010. The Web site assessed was the production environment at http://demo.testfire.net/.

 

.

Industry leading tools were used to remotely perform the automated portion of the assessment in conjunction with manual analysis and review process.  This report documents and prioritizes discovered vulnerabilities.

 

The application is written in .NET The application uses Java Script and Cascading Style Sheets.

 

The application is a fake banking application.

Conclusion and Recommendations

We have documented the detailed opportunities to improve the security posture of the application.  It is recommended that the High vulnerabilities be addressed as soon as possible (3 months or less).  Parsons Software  Security Consulting, LLC, is an advisor for your team to utilize to assist in the remediation process.

Proper coding practices using whitelisting, should be instituted. Whitelisting would state that anything that is not specifically allowed is denied. For instance, if a field should only require alphabetic characters, then only those characters should be allowed in that field. This will not only help defend against certain kinds of attacks but also help keep data that is accepted as accurate as possible.

Error handling and trapping should be instituted throughout the application and the server.  This will prevent information leakage via error messages resulting from unexpected input from users.  Error messages generated should be uniform and uninformative, to prevent them from unintentionally revealing information.

 

 

 

 

 

 

 

 

 

 

 

 

 

Overview of Web Application Findings

The following Vulnerabilities were discovered:

 

Risk Level Vulnerability Description
High Authentication Bypass SQL injection.  An attacker could bypass the login page and login to the application without credentials.
High SQL injection.  An attacker could extract sensitive data from the database.
High Blind SQL injection.     An attacker could extract sensitive data from the database.
High Cross Site Scripting.  An attacker could deface your website or steal customer’s credentials and data.
Medium Database Error Found.  Database error found can give information for an attack later on.
Medium Direct Access to Administration Pages.  This could reveal highly sensitive information about your website.
Medium Sensitive Files Found.   This could reveal highly sensitive information about your website.
Low Cross Site Request Forgery.  This could allow an attacker to attack your website via a  client.
Low Unencrypted Login Request.  This could allow an attacker to steal user’s credentials.
Low Form Auto Complete On.

 

 

 

 

 

 

 

 

 

 

Web Application Assessment Details

 

Assessment Scope

 

Note: This assessment took place during the month of November, 2010. All vulnerabilities described relate to the site configuration, as it existed at the time, and may or may not be applicable to the current configuration state.

Credentials were used for the assessment.

 

Findings and Recommendations

The findings below are ordered by risk, with an emphasis on remediation steps to obviate the exposure. Where possible, references are given for hardening and best practices guidelines that apply to the exposure in question.

 

Vulnerability risk definition is as follows:

 

High Risk – These findings identify conditions that could directly result in the compromise or unauthorized access of a network, system, application or information.

 

Medium Risk – These findings identify conditions that do not immediately or directly result in the compromise or unauthorized access of a network, system, application or information, but do provide a capability or information that could, in combination with other capabilities or information, result in the compromise or unauthorized access of a network, system, application or information.

Low Risk – These findings identify conditions that do not immediately or directly result in the compromise of a network, system, application, or information, but do provide information that could be used in combination with other information to gain insight into how to compromise or gain unauthorized access to a network, system, application or information. Low risk findings may also demonstrate an incomplete approach to or application of security measures within the environment.

In many cases issues that were discovered in one location were replicated throughout the application. Thus, the remediation processes may overlap with other discovered vulnerabilities and should be implemented on an application wide basis.

 

Vulnerability 1 Authentication / Weak Authentication
Risk High
Reference http://www.kb.cert.org/vuls/id/466433

 

See Vimeo Reference http://vimeo.com/17196966

Affected URLs http://demo.testfire.net/bank/login.aspx

Vulnerability Description

The application has a weak authentication mechanism. As a result, it is possible to bypass the requirement of registering in order to access the literature section of the site. The authentication seems to rely completely on whether or not “username=” is set as part of the “pref” cookie. If any username is set, the user can access the restriction part of the site. The rest of the cookie, including the “password=” portion, is ignored.

 

 

 

Vulnerability Recommendation

The authentication mechanism should check both username and password to verify session validity. Once validity has been established, the session should be connected to a session identifier value to help prevent tampering. Typically, this session ID is stored into a cookie. Subsequently, the session identifier should be checked at each protected page to ensure it is connected with a valid, authenticated session. Only then should the protected page be shown to the user.

 

 

 

Vulnerability Recommendation

This file should be removed from the system. Also, the process of in place backups should be discontinued. This will help ensure sensitive information is not leaked to attackers.

 

Vulnerability 2 Input Validation / SQL Injection
Risk High
Reference  
Affected URLs http://demo.testfire.net/

http://demo.testfire.net/bank/account.aspx

http://demo.testfire.net/bank/login.aspx

http://demo.testfire.net/bank/transaction.aspx

http://demo.testfire.net/bank/transfer.aspx

http://demo.testfire.net/subscribe.aspx

Vulnerability Description

A potential SQL injection vulnerability was identified. This may allow an attacker to gain sensitive information and affect the back end database.  Even though no sensitive data was retrieved, it should be ensured that this condition does not exist in code. The symptoms appear to be there.

See Vimeo Reference http://vimeo.com/17196966

 

 

 

 

Vulnerability Recommendation

 

SQL Injection arises from an attacker’s manipulation of query data to modify query logic. The best method of preventing SQL Injection attacks is thereby to separate the logic of a query from its data. This will prevent commands inserted from user input from being executed. The downside of this approach is that it can have an impact on performance, albeit slight, and that each query on the site must be structured in this method for it to be completely effective. If one query is inadvertently bypassed, that could be enough to leave the application vulnerable to SQL Injection. The following code shows a sample SQL statement that is SQL injectable.

sSql = “SELECT LocationName FROM Locations “;

sSql = sSql + ” WHERE LocationID = ” + Request[“LocationID”];

oCmd.CommandText = sSql;

The following example utilizes parameterized queries, and is safe from SQL Injection attacks.

$db = new mysqli(“localhost”, “user”, “pass”, “database”);

$stmt = $db -> prepare(“SELECT priv FROM testUsers WHERE username=? AND password=?”);

$stmt -> bind_param(“ss”, $user, $pass);

$stmt -> execute();

 

In PHP version 5 and MySQL version 4.1 and above, it is possible to use prepared statements through vendor-specific extensions like mysqli.

The application will send the SQL statement to the server without including the user’s input. Instead, a parameter-?- is used as a placeholder for that input. In this way, user input never becomes part of the command that SQL executes. Any input that an attacker inserts will be effectively negated. An error would still be generated, but it would be a simple data-type conversion error, and not something a hacker could exploit.

Input validation should be happening on all input coming from a user. The vast majority of SQL Injection checks can be prevented by properly validating user input for both type and format. The best method of doing this is via “white listing”. This is defined as only accepting specific account numbers or specific account types for those relevant fields, or only accepting integers or letters of the English alphabet for others. Many developers will try to validate input by “black listing” characters, or “escaping” them. Basically, this entails rejecting known bad data, such as a single quotation mark, by placing an “escape” character in front of it so that the item that follows will be treated as a literal value. This approach is not as effective as white listing because it is impossible to know all forms of bad data ahead of time.

 

 

Vulnerability 3 Input Validation / Potential Blind SQL Injection
Risk High
Reference  
Affected URLs http://demo.testfire.net/bank/login.aspx

Vulnerability Description

A potential Blind SQL injection vulnerability was identified. This may allow an attacker to gain sensitive information and affect the back end database even though database error messages are not being displayed. Even though no sensitive data was retrieved, it should be ensured that this condition does not exist in code. The symptoms appear to be there. The variable identified is the “uid” variable on the following page:

 

 

See Vimeo Reference http://vimeo.com/17196966

 

 

 

Vulnerability Recommendation

 

SQL Injection arises from an attacker’s manipulation of query data to modify query logic. The best method of preventing SQL Injection attacks is thereby to separate the logic of a query from its data. This will prevent commands inserted from user input from being executed. The downside of this approach is that it can have an impact on performance, albeit slight, and that each query on the site must be structured in this method for it to be completely effective. If one query is inadvertently bypassed, that could be enough to leave the application vulnerable to SQL Injection. The following code shows a sample SQL statement that is SQL injectable.

sSql = “SELECT LocationName FROM Locations “;

sSql = sSql + ” WHERE LocationID = ” + Request[“LocationID”];

oCmd.CommandText = sSql;

The following example utilizes parameterized queries, and is safe from SQL Injection attacks.

$db = new mysqli(“localhost”, “user”, “pass”, “database”);

$stmt = $db -> prepare(“SELECT priv FROM testUsers WHERE username=? AND password=?”);

$stmt -> bind_param(“ss”, $user, $pass);

$stmt -> execute();

 

In PHP version 5 and MySQL version 4.1 and above, it is possible to use prepared statements through vendor-specific extensions like mysqli.

The application will send the SQL statement to the server without including the user’s input. Instead, a parameter-?- is used as a placeholder for that input. In this way, user input never becomes part of the command that SQL executes. Any input that an attacker inserts will be effectively negated. An error would still be generated, but it would be a simple data-type conversion error, and not something a hacker could exploit.

Input validation should be happening on all input coming from a user. The vast majority of SQL Injection checks can be prevented by properly validating user input for both type and format. The best method of doing this is via “white listing”. This is defined as only accepting specific account numbers or specific account types for those relevant fields, or only accepting integers or letters of the English alphabet for others. Many developers will try to validate input by “black listing” characters, or “escaping” them. Basically, this entails rejecting known bad data, such as a single quotation mark, by placing an “escape” character in front of it so that the item that follows will be treated as a literal value. This approach is not as effective as white listing because it is impossible to know all forms of bad data ahead of time.

 

 

Vulnerability 4 Input Validation / Cross-Site Scripting (XSS)
Risk High
Reference http://www.cgisecurity.com/articles/xss-faq.shtml
Affected URLs
lang

See Vimeo Reference

http://demo.testfire.net/bank/customize.aspx

 

http://www.vimeo.com/17200635

uid http://demo.testfire.net/bank/login.aspx
debitAccount http://demo.testfire.net/bank/transfer.aspx
creditAccount http://demo.testfire.net/bank/transfer.aspx
name http://demo.testfire.net/comment.aspx
comment.aspx http://demo.testfire.net/comment.aspx
txtSearch http://demo.testfire.net/search.aspx
txtEmail http://demo.testfire.net/subscribe.aspx

 

Vulnerability Description

Multiple instances of Cross-Site Scripting were identified. This vulnerability could allow an attacker to craft a malicious link or get malicious code inserted in to a user’s browser. Normally this is used to steal session identifiers or credentials allowing them to compromise the application’s data. This vulnerability could also be used to insert malicious content in to the user’s browser potentially compromising their system. The recommendation for this issue should be applied anywhere where the application accepts data from a user and it gets echoed back to the screen. A list of some of the identified URLs with XSS issues are listed in Appendix A. Some of the URLs may have multiple variables that are vulnerable.

The following shows a XSS vulnerability and a popup of document.cookie.

 

lang

See Vimeo Reference

http://demo.testfire.net/bank/customize.aspx

 

http://www.vimeo.com/17200635

 

 

 

 

 

Vulnerability Recommendation

Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. Always use as strict a pattern as you can possibly allow. Encoding of output ensures that any scriptable content is properly encoded for HTML before being sent to the client.

Be sure to consider all paths that user input takes through your application. For instance, if data is entered by the user, stored in a database, and then redisplayed later, you must make sure it is properly encoded each time it is retrieved. If you must allow free-format text input, such as in a message board, and you wish to allow some HTML formatting to be used, you can handle this safely by explicitly allowing only a small list of safe tags.

Secure coding practices, sanitization of user input, and properly encoding output should be used. The application should only accept content for which it is expecting for that particular variable. If a variable is only needing to accept alphabetic characters then it should only allow a-z and other characters should be denied. Encoding of the output ensure that any scriptable content is properly encoded for HTML before being sent to the client. This code would properly encode items such as <, >, \, \\, and & with their proper HTML equivalents such as &lt; &gt; &quot; etc.

 

 

Vulnerability 5 Information Leakage / Verbose Database Error Messages
Risk High
Reference http://msdn.microsoft.com/en-us/library/994a1482.aspx
Affected URLs
amUserId http://demo.testfire.net/
listAccounts http://demo.testfire.net/bank/account.aspx
uid http://demo.testfire.net/bank/login.aspx
passw http://demo.testfire.net/bank/login.aspx
login.aspx http://demo.testfire.net/bank/login.aspx
before http://demo.testfire.net/bank/transaction.aspx
after http://demo.testfire.net/bank/transaction.aspx
transaction.aspx http://demo.testfire.net/bank/transaction.aspx
debitAccount http://demo.testfire.net/bank/transfer.aspx
creditAccount http://demo.testfire.net/bank/transfer.aspx
txtEmail http://demo.testfire.net/subscribe.aspx
subscribe.aspx http://demo.testfire.net/subscribe.aspx

 

Vulnerability Description

The database is sending verbose errors to the user’s browser. These errors indicate an unhandled exception by the database server. This information contains sensitive information that an attacker can use to conduct further attacks. It gives an attacker helpful information regarding syntax of requests in which the attacker can use to correct mistakes and increase the effectiveness of attacks.

 

See Vimeo Reference http://vimeo.com/17196966

 

 

 

Vulnerability Recommendation

The best way to prevent these errors is proper coding techniques in which only proper input is accepted. This should be done in a whitelisting approach. Do not display error messages to the end-user that provide information (such as table names) that could be utilized in orchestrating an attack. Also, there should be definition of the maximum and minimum data lengths for what the application will accept. ODBC error messages should be turned off and raw ODBC and other verbose errors should not be sent to the end user. To remove detailed error messages documentation for the particular database server should be consulted.

 

 

 

Vulnerability 6 Admin Directory
Risk Medium
Reference  
Affected URLs http://demo.testfire.net/admin/

Vulnerability Recommendation
A directory named ‘admin’ was discovered within your web application. Risks associated with an attacker discovering an administrative directory on your application server typically include the potential for the attacker to use the administrative applications to affect the operations of the web site.

 

 

 

 

Vulnerability 7 Information Leakage / Directory Listing/ Sensitive files
Risk Medium
Reference  
Affected URLs http://demo.testfire.net/bank/

http://demo.testfire.net/pr/

Vulnerability Description

The application has several files that appear to be in place backups of files. These files are sometimes served differently by the web server than files with the standard file extension. In some cases this could lead to information leakage that would give an attacker an idea of how to better attack the system.

 

 

See Vimeo Reference http://www.vimeo.com/17200961

 

 

 

 

 

 

 

 

 

 

Vulnerability Recommendation

These files should be removed from the system and the process of doing in place backups such as this should be discontinued. This will ensure that the server doesn’t accidentally serve sensitive data to an attacker.

 

Vulnerability 8 Cross Site Request Forgery
Risk High
Reference  
Affected URLs
admin.aspx http://demo.testfire.net/admin/admin.aspx
account.aspx http://demo.testfire.net/bank/account.aspx
apply.aspx http://demo.testfire.net/bank/apply.aspx
customize.aspx http://demo.testfire.net/bank/customize.aspx
logout.aspx http://demo.testfire.net/bank/logout.aspx
transaction.aspx http://demo.testfire.net/bank/transaction.aspx
transfer.aspx http://demo.testfire.net/bank/transfer.aspx
comment.aspx http://demo.testfire.net/comment.aspx
subscribe.aspx http://demo.testfire.net/subscribe.aspx

 

Vulnerability Description

In order to avoid CSRF attacks, every request should contain a unique identifier, which is a parameter that an attacker cannot guess.

Vulnerability Recommendation

One suggested option is to add the session id taken from the session cookie and adding it as a parameter. The server must check that this parameter matches the session cookie, and if not discard the request. The reason an attacker cannot guess this parameter is the “same origin policy” that applies to cookies, so the attacker cannot forge a fake request that will seem real to the server. Any secret that is hard to guess and is not accessible to an attacker (i.e. not accessible from a different domain) can be used instead of the session id. This will prevent an attacker from crafting a seemingly valid request.

 

 

 

Vulnerability 9 Session Handling / Cleartext connections
Risk High
Reference http://www.kb.cert.org/vuls/id/466433
Affected URLs
http://demo.testfire.net/bank/customize.aspx
http://demo.testfire.net/bank/queryxpath.aspx
http://demo.testfire.net/bank/transaction.aspx

 

Vulnerability Description

The application accepts session data over plaintext connections. Sending credentials and data without cryptographic protections could allow for an attacker to intercept this data allowing them to take actions in the intercepted user’s name. Also if cryptographic protections such as TLS/SSL are not used the data being sent or received from the application can be modified. People often use the same password for multiple services. A password intercepted here could allow for its use elsewhere.

 

 

 

 

 

 

Vulnerability Recommendation

 

The application should use some form of cryptographic protection for credentials and session IDs being sent. This will mitigate the risk of not only the capturing of authentication data but the integrity of data being pulled and submitted to the application as well. Most commonly for web applications this is done with TLS/SSL.

 

Vulnerability 10 Form Auto-complete ON
Risk Low
Reference http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/abbca505-6f63-4267-aac1-1ea89d861eb4.mspx
Affected URLs http://demo.testfire.net/bank/login.aspx

 

Vulnerability Description

 

Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment.

 

 

Vulnerability Recommendation

Recommendations include setting auto complete to “off” on all your forms.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Sources and Further Reading

OWASP: The Open Web Application Security Project

http://www.owasp.org

 

The Web Application Security Consortium

http://www.webappsec.org

 

Mark Kruger: The Application Security Pyramid

http://www.coldfusionmuse.com/index.cfm/2006/4/13/security.pyramid.policing

 

OWASP Top Ten 2007

http://www.owasp.org/index.php/Top_10_2007

 

OWASP Security Principles

http://www.owasp.org/index.php/Category:Principle

 

OWASP Common Software Vulnerabilities

http://www.owasp.org/index.php/Category:Vulnerability

 

Microsoft: Improving Web Application Security

http://msdn2.microsoft.com/en-us/library/ms994921.aspx

 


Web Application Assessment Points of Contact

For questions or comments regarding this report please contact the following:

Name Role Contact Information
Matt Parsons, MSM, CISSP Vice President, Parsons Software Security Consulting, LLC mparsons1980@gmail.com

315-559-3588

 

 

 

Written by mparsons1980

November 29, 2010 at 4:18 pm

Posted in Uncategorized