http://www.meetup.com/OWASP-Northern-Virginia-Chapter/events/112674542/

With the need to connect over 20 Billion devices by 2020, the IPv4 Internet with its maximum of 4 billion addresses has run out of steam. The impact has been more complexity for networks, operations and applications. In fact, the implementation of Network Address Translation requires all devices between the web user and the web application to add more complex code, which has lead to slower operation and higher cost to develop and manage systems.

IPv4′s replacement as of June 2012, IPv6, is considered ready for prime time. Today, over 1.5% Internet connect via IPv6 to Google every day. In short, IPv6 is no longer a should, but a must. That is, if you plan on staying in business and connected with your customers. This presentation will discuss:

• How do you know your customers are using IPv6?
• What methods of implementations are available and what are their impacts?
• What changes need to be made on your ISP, networks, applications,logging and security to support IPv6?
• What are some of the security issues that may arise if not implemented correctly?

Where

LivingSocial
11600 Sunrise Valley Drive, Reston, VA

When
Thursday, April 11, 2013 6:30 PM

If you have a software development lifecycle (SDLC) that takes security into account, you likely do an assessment of the application before it goes into production. If it’s a mature process, you might even be setting security requirements, conducting threat modeling, and have secure coding standards. Once that application is live, the process shouldn’t stop.

While my own observations may be largely anecdotal, there are two web application security frameworks that track common security practices among organizations with mature software development programs: the Building Security in Maturity Model, and OWASP’s Software Assurance Maturity Model. Both leave out the concept of continuous web application vulnerability scanning.

What follows are my thoughts about building out a vulnerability management program to include vulnerability scanning of live, customer facing web applications.

Goals of Continuous Web Application Vulnerability Scanning

• Understand web application specific risk exposure and bring that in-line with policies.
• Integrate results with development efforts to improve code quality.

Challenges of Web Application Vulnerability Management

• Infrastructure fixes tend to have cookie cutter solutions (apply a patch, or change a configuration) versus a full custom software development effort with web applications.
• Some applications may no longer be under active development or may not have development environments and deployment procedures.

Web Application Security Frameworks

Software development has a set of security best practices that entails a variety of activities. Below is the OWASP Open Software Assurance Maturity Model. While the framework leaves continuous web application vulnerability scanning of live applications out as a specific activity, it would fit into two of the high level security practices: security testing and vulnerability management.

Vulnerability Management Process

According to Gartner, vulnerability management follows this cycle: define policy, baseline environment, assess risk, shield against exploitation, mitigate vulnerabilities, and metrics reporting. The following are points specific to web application vulnerability management.

Policy

• Define secure web application policy, standards, and specifications.
• Ensure policies for secure software development and risk acceptance exist in your organization.

Baseline

Define application portfolio and attack surface. Create an inventory.

• Use an application to track inventory and vulnerabilities; having both is key.

Information required for each application:

• Entry URL
• Test Login Credentials
• Date/Time most appropriate for scanning

Additional Information:

• Points of Contact – application owner, development team
• Defect Tracking System in use
• Data Items/Classification (PII, CHD, etc…)
• Priority/Risk

Make sure you communicate to the appropriate teams and key people that you are scanning production applications. Get explicit approval if applicable! A misstep involving knocking over an application no one knew you were looking at early in the process might have disastrous political repercussions.

Prioritize/Assess

Use business risk and development effort to prioritize remediation efforts. Involve development teams, and frame the vulnerability as a kind of software defect.

Shield

Use custom rules in WAF or web relevant IDS/IPS to temporary block (or at least detect) exploitation attempts.

Mitigate

• Communicate business risk and compliance implications of vulnerabilities.
• If commercial off the shelf software (COTS), is there a patch?
• Treat web application security vulnerabilities as software defects, and enter the information into the defect tracking system in use.
• Work into development schedules as resources are available.
• Have a procedure for out-of-cycle releases for serious vulnerabilities.

Maintain

Web applications are dynamic and attacks evolve – this is an ongoing process. Create a schedule for continuous web application vulnerability scanning and follow-up to mitigation efforts.

Metrics & Reporting

• Vulnerabilities: Raw number, number per app
• Risk Ratings
• Defect correction rate – Time to Remediation
• Security defect density – security defects per lines of code
• Risk Density – adds a risk rating to defect density (1 high risk vulnerability per 100 lines of code)
• Scan Code Coverage – how much of the application surface is being scanned (authenticated vs. unauthenticated, logic that scanner isn’t getting beyond, etc…)
• Company Top 5 – like OWASP top 10, but organization specific
  • This could include data from any security incidents

Other Considerations

• Provide feedback to development teams – preventing vulnerabilities is much cheaper than fixing them in production.
• If you have an SDLC in place, add continuous web application vulnerability scanning to the official process.
• If this is your first foray into web application vulnerability scanning in your company, be sure to do an assessment of any new applications before they are exposed to the Internet.

Tools

There are a lot of web application vulnerability scanners to choose from – some are free and open source. You also need a good way to track issues once you find them. Check out these sources for a good overview of the available tools.

• Fantastic overview and comparison of both commercial and open source web application vulnerability scanners: http://sectooladdict.blogspot.com/2011/08/commercial-web-application-scanner.html
• Gartner Magic Quadrant for web application vulnerability scanners: http://www.gartner.com/technology/reprints.do?id=1-18GM74P&ct=111228&st=sb
• Once you find vulnerabilities, you need to track and remediate them. The Denim Group has a tool called Threadfix that both tracks software vulnerabilities and integrates with software defect tools. http://www.denimgroup.com/resources-threadfix/index.php

References

• http://www.gartner.com/DisplayDocument?doc_cd=127481
• http://www.bsimm.com
• http://www.opensamm.org/downloads/SAMM-1.0.pdf

NoVa ISSA Chapter Meeting

http://www.issa-nova.org/

Where: Oracle Corporation, 1900 Oracle Way, Reston, VA 20190
When: Thursday , February 21st
Time: 5:30

The Beauty of Surveillance

Network traffic and logs are the backbone of intrusion detection. Through a normal production system deployment, host and network logs capture all kinds of different information that provides insight into past and ongoing security breaches. How do security teams know which attack or infection matters to their organization? What are the different identifiers that might hold a key piece of information into malicious activity? Does a red flag need to be raised on a piece of commodity malware? Let us find out how to use correlation and active intelligence to hasten an investigation and potentially bring a targeted attack to a halt.

Where: Roosters Wings

3370 Olentangy River Road
Columbus, OH 43202

http://www.eventbrite.com/event/3917647790

• OWASP Zed Attack Proxy (ZAP): https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
• Skipfish: http://code.google.com/p/skipfish/
• WAPITI: http://wapiti.sourceforge.net/
• Web Application Attack and Audit Framework: http://w3af.sourceforge.net/

Requirements

1. No UI interaction: the tool either needs to be launched via web service or command line.
2. Provide some output: the tool should produce a useful report.
3. Operating system does not matter: the tool can run on Windows or Linux.

Outside Independent Testing

Research was done to find independent comparisons of web application vulnerability scanners. The following source outlines one such test of over 60 commercial and open source tools.

http://sectooladdict.blogspot.com/2011/08/commercial-web-application-scanner.html

The tools we are looking at were compared in both cross-site scripting and SQL injecting tests.

Cross Site Scripting Detection

SQL Injection Detection

WAPITI

WAPITI was immediately discounted because it appears to be an abandoned project. While outside testing gives it OK marks, it hasn’t been updated since 2009. It lacks support in basic web application functionality like SSL.

Skipfish

Skipfish is stable and the scanner is easy to launch, but the reporting isnít very detailed.

It seems to be an incredibly stable tool and it is very easy to launch. One particular OCLC product caused the other tools I typically use for a first-pass analysis to either fail completely or return bad results. Skipfish ran for 5 days without an issue, and gave me a set of workable results. To launch, itís as easy as choosing a dictionary, and pointing it to the test application.

OWASP has a script for Skipfish Automation – https://www.owasp.org/index.php/Automated_Audit_using_SKIPFISH

The report Skipfish produces is aimed towards the web application security expert. It lists issues and the URL they can be found without providing any detail of their implications or advice on how to fix them. I think, at least at first, you’d have to do a good deal of research to make the results useful.

Web Application Attack and Audit Framework

w3af has a variety of plugins to run each security test. When it is launched via command line, you have to select each one individually. I could certainly help in setting up a usable profile of plugins. In the following example, I simply want to spider a site to look for cross site scripting issues.

OWASP has a guide on automated scanning using w3af, along with some good starting plugins here: https://www.owasp.org/index.php/Automated_Audit_using_W3AF

The report is a little more useful than the one from SkipFish. It gives you the vulnerability, the parameters involved, and assigns a severity. It does not, however, give you much in the way of remediation advice.

OWASP ZAP

OWASP’s Zed Attack Proxy (ZAP) automation is different. It does not work via command line, but uses API calls. Because it is a proxy using API calls, it allows for integration in a regression testing workflow. I think it would take the longest to get this setup as you’d have to build some logic around the scan flow. This scanner has the least information online on setting up a headless scan (there is a lot on using the UI, but not much on automation). I was able to get ZAP to crash. Its output seems a little more useful than the others as it gives a description and some remediation advice. However, the reporting mechanism seems immature – the report is long and redundant, flagging the same issue several times.

There is a little information here: http://code.google.com/p/zaproxy/wiki/FAQhowtousezapapi

You start the Zed Attack Proxy headless, and it acts as a proxy as you do your other testing. Using a -daemon tell the UI not to start.

It starts a proxy on port 8080, and I set Firefox to use localhost:8080 as a proxy to all web traffic. Going to http://zap/ in the browser gives you a menu of API options.

With ZAP as a proxy, run all of your other tests. Then, using the API calls, you kick off the ZAP spider and scan.

• http://zap/XML/ascan/action/spider/?url=http://192.168.1.109/bodgeit
• http://zap/XML/ascan/action/scan/?url=http://192.168.1.109/bodgeit

You would have to build a little logic around the scan. There is nothing that tells you when a spider or a scan is done besides an XML error telling you a scan is in progress if you try to scan before the spider is finished.

The output looks like this:

Conclusion

Performing security testing early in the application development process would allow for early detection of vulnerabilities. Fixing application defects early in the process is much cheaper than addressing them once an application is in production. In addition, getting almost immediate feedback on security issues would help raise awareness and education of security issues within the development community.

I recommend w3af for inclusion in a CI environment. It has the best balance of ease of use, vulnerability detection, and meaningful reporting. Also, the w3af project is backed by Rapid7 ñ giving it resources for improvement and continued development.

Skipfish and ZAP are also useful. Although, I feel that Skipfishís report was too lacking and ZAP would be too difficult to setup initially. However, hese obstacles may be easy to overcome with an in depth tools skill set.

PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, and ATM cards. Defined by the Payment Card Industry Security Standards Council, the standard was created to increase controls around cardholder data to reduce credit card fraud via its exposure. Validation of compliance is done annually — by an external Qualified Security Assessor (QSA) for organizations handling large volumes of transactions, or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes.

PCI DSS has 6 main goals, and 12 high level requirements. They are as follows:

The full standard can be found here: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

Who and When?

Any organization that accepts payment cards or stores, processes, or transmits credit or debit card data must comply with the PCI DSS. Further, all deadlines for compliance have passed. NOW is the time to be compliant.

What do I need to do?

The rest of this post will address this at a high level, specifically for a level 4 merchant. In short, you need to comply with all of the PCI DSS. However, the validation requirements, that is how you prove your compliance, differs based on the following:

• Merchant or Service Provider status
• Transaction volume
• Card brand
• Method of accepting and interacting with card data

Step 0 – a: Determine Merchant Level

A merchant is any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services.

A service provider is a business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. I was not working with a service provider, so any additional information is out of scope.

Your merchant level is based on your volume of transactions, and differ slightly per brand. It largely determines whether you need a qualified security assessor (QSA), or if a self-assessment questionnaire (SAQ) is appropriate.

Step 0 – b: Determine Appropriate SAQ

SAQ high level instructions: https://www.pcisecuritystandards.org/documents/pci_dss_saq_instr_guide_v2.0.pdf

The SAQ D is the most complex, and goes through the PCI DSS in its entirety. If you are unsure which SAQ to go with, D will cover all of your bases. If you want to do a gap assessment before a QSA comes in, I would go through the SAQ D to ensure you’re ready.

Step 1: Determine PCI Scope

In short, you need to identify all systems, personnel, and processes involved in the transmission, processing, or storing of cardholder data. It is worth taking your time to ensure this is as accurate as possible. Surprises can and probably will come up, but knowing the scope before diving into the assessment will save time later.

The first step of a PCI DSS compliance effort is to accurately determine the scope of the environment. The scoping process includes identifying all system components that are located within or connected to the cardholder data environment (CDE). The cardholder data environment is comprised of people, processes, and technology that handle cardholder data or sensitive authentication data. System components include network devices (both wired and wireless), servers, and applications.

• The assessed entity identifies and documents the existence of all cardholder data in their environment. (results may be a diagram or an inventory of cardholder data locations).
• Any cardholder data found to be in scope of the PCI DSS assessment is part of the CDE unless such data is deleted or migrated/consolidated into the currently defined CDE.

I found it helpful to hold a series of scoping meetings. I did some initial legwork to determine which applications might have credit card data, and then had meetings to go over the architecture of each with the appropriate teams. I did the same with different manual processes for receiving orders and payment collection. After each meeting I created a data flow diagram in Visio. After I had an idea of data flows and application architecture, I constructed a diagram of our CDE.

1. Document the cardholder data flow. Define all of the applications involved as well as which systems actually store cardholder data.
   • http://en.wikipedia.org/wiki/Data_flow_diagram 
2. Develop a network diagram that documents all of the network devices (routers, firewalls, access points, etc…) and servers attached to the CDE, and how they are architected.
   • http://www.fishnetsecurity.com/6labs/blog/pci-dss-and-network-diagram 
   • http://stateofsecurity.com/?p=1875 
3. Ensure you have the entire scope. Scan environment to see if card holder data (CHD) is stored anywhere outside of the CDE.
   • http://www2.cit.cornell.edu/security/tools/
   • Database Searches

Step 2: Assess

Use the appropriate SAQ to guide the assessment, and appropriate technologies to locate insecure systems.

Resources:

• PCI DSS v2: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf 
• Navigating PCI DSS: https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf 
• Quick Reference: https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf 
• SAQ Download Page: https://www.pcisecuritystandards.org/security_standards/documents.php?category=saqs 

I held a series of interviews with different teams to go over the section(s) of the SAQ relevant to their job. They were usually quick, between 30 minutes and an hour each. I would start by giving a high level description of PCI DSS. Then I would show them the CDE diagram and make sure they knew that the questions were only relevant to that scope. This is why knowing the scope in advance and having that scope be as small as possible makes this easier – if you know only 3 Windows servers are in scope, it is easier for the IT personnel dealing with those to wrap their head around than talking about their entire environment.

Before each interview I did my homework by reading the appropriate section of the PCI DSS, and PCI’s “Navigating PCI DSS” document so I could best explain the question being asked.

Step 3: Remediate

Remediate any non-compliances you find. A big one being, do not store cardholder data unless you need it. Even at this stage, it isn’t too late to simplify processes and get rid of unneeded data. The smaller your scope, the easier your job is. PCI has laid out a prioritized approach to remediation. If you’re early in your compliance efforts, you might find it helpful to break things out in the recommended milestones.

• https://www.pcisecuritystandards.org/documents/Prioritized_Approach_V2.0.pdf 
• https://www.pcisecuritystandards.org/documents/Prioritized_Approach_for_PCI_DSS_v20.xls

Step 4: Report

Regular reports are required for PCI DSS compliance; these are submitted to the acquiring bank and payment card brands that you do business with. Compile and submit required remediation and validation records (if applicable), and submit compliance reports to the appropriate places.

Complete a passing self assessment questionnaire (SAQ) and attestation of compliance (AOC).

• SAQ/AOC Download Page: https://www.pcisecuritystandards.org/security_standards/documents.php?category=saqs

Depending on your acquiring bank’s requirements, you might have to submit your quarterly compliant scan results either once a quarter or annually. No matter what your requirement, you need to run them and show compliant results at least quarterly.

Other Resources

PCI Compliance Dashboard (Spreadsheet): https://community.rapid7.com/docs/DOC-1512
Open PCI DSS Scoping Toolkit: http://itrevolution.com/wp-content/uploads/2012/08/OpenPCIScopingToolkit.pdf
PCI Compliance (Amazon Book) 

Here is the presentation I gave at Derbycon.

Download PDF.

Abstract

This presentation will introduce SQL injection to the new web application hacker. It will walk you through web architectures and vulnerable code examples. You will learn how to set up a penetration testing lab with vulnerable applications, find SQL injection vulnerabilities, and hack them to bits. After you understand the problem, you’ll learn how to prevent them in the first place.

Additional Information and Research (In-Depth Blog Posts)

• SQL Injection Defined
• Detecting SQL Injection Vulnerabilities

• SQL Injection Defined
• Detecting SQL Injection Vulnerabilities

Testing by Inference

SQL injection is an attack technique used to exploit applications by altering back-end SQL statements through manipulating input. Web applications build SQL statements dynamically that contain data provided at runtime by the user or application. If an attacker can control that input and manipulate the data so it is interpreted as code, he may be able to execute code against the back-end database.

When testing web applications, you usually do not have access to its source code and can’t see the SQL query you are trying to inject code into. You have to perform much of your testing through inference. – that is, “if I see this, then this is probably happening at the back end.” Our main goal in vulnerability detection is to identify anomalies in the appliction response to determine whether they are generated by a SQL injection vulnerability.

Let’s consider a retail application that’s to display a category of products the user wants to see.

URL:

www.MyAwesomeStore.com/buystuff.php?category=balls

Without properly handing this input, anything entered as the “category” parameter could be entered directly in a SQL query – that is, under the attacker’s control.

SQL:

SELECT *
FROM products
WHERE category=’[attacker’s control]’

Generating an Application Error

One way to detect SQL injection vulnerabilities is to insert unexpected characters as input that might change the query in such a way that it breaks. If we enter characters that have a special meaning in SQL and get an application error, we can infer that our input is being used in a vulnerable way in a SQL query. A single quote (‘) marks the beginning or end of data, a semicolon (;) marks the end of a SQL statement, and two dashes (–) mark a SQL comment – all of which have the potential to generate errors.

Let’s use the single quote as an example. If you were to enter the single quote character as input to the application in our example in the URL as a “category”, you’ll be presented with an error. The reason for the error is that the single quote character has been interpreted as a string delimiter. Syntactically, the SQL query executed at runtime is incorrect (it has one too many string delimiters), and therefore the database throws an exception. The character is used in SQL injection attacks to “escape” the developer’s query so that the attacker can the construct his own quires and have them executed.

URL:

http://www.MyAwesomeStore.com/buystuff.php?category=attack’

SQL:

SELECT *
FROM products
WHERE category=’attack’’

Error:

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /var/www/myawesomestore.com/buystuff.php on line 12

Examples of SQLi Errors from Different Databases and Languages

Microsoft SQL Server

Server Error in ‘/’ Application. Unclosed quotation mark before the character string ‘attack;’.

Description: An unhanded exception occurred during the execution of the current web request. Please review the stack trace for more information about the error where it originated in the code.

Exception Details: System.Data.SqlClient.SqlException: Unclosed quotation mark before the character string ‘attack;’.

MySQL Errors

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /var/www/myawesomestore.com/buystuff.php on line 12

Error: You have an error in your SQL syntax: check the manual that corresponds to your MySQL server version for the right syntax to use near ‘’’ at line 12

Oracle Errors

java.sql.SQLException: ORA-00933: SQL command not properly ended at oracle.jdbc.dbaaccess.DBError.throwSqlException(DBError.java:180) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)

Error: SQLExceptionjava.sql.SQLException: ORA-01756: quoted string not properly terminated

PostgreSQL Errors

Query failed: ERROR: unterminated quoted string at or near “‘’’”

Other Errors

If you see the above errors you can be almost certain the application is vulnerable to some kind of SQL injection vulnerability. You could also be presented with a custom, default, or generic error message, or an HTTP 500 error. If while testing a website you discover that the application is responding with such an error, you will need to make sure the error is due to SQL injection. You can test this by inserting meaningful SQL code into the parameter without trigging an application error.

Manual Testing

Let’s see what this looks like in a sample application. Using The BodgeIt Store, a vulnerable web application aimed at people learning to pen test, let’s inject a single tic (‘) and see what happens.

Username: user’
Password: password

Our single quote generated a custom appellation error. Let’s add some additional meaningful SQL and see  what happens.

Username: user’ or ’1′ = ’0
Password: password

With meaningful, syntactically correct SQL, the application error goes away thus validating that we have a SQL injection vulnerability.

Automated Testing: Browser Plugins

Browser extensions are particularly helpful because of their convenience – the tool is at your fingertips as you are browsing the web. Being built in to the browser gives them the ability to manipulate what you’re seeing in a UI that’s already familiar.

SQL Inject Me by Security Compass is a Firefox extension that will run a series of tests against a web form. It opens in a side bar next to the web page you’re viewing and allows you to assess that page with the click of a button.

Tamper Data is a Firefox extension that acts as a built in proxy. It allows you to view and modify HTTP headers and post parameters. If you right click on a parameter, it gives you options to modify it with an SQLi test.

Automated Testing: Web Application Vulnerability Scanners

Web application vulnerability scanners communicate with an application through the web front-end in order to identify potential security vulnerabilities and architectural weaknesses. First they spider the application to find each page and input. Then, they fuzz those inputs looking for responses that indicate security issues. This scan can detect issues including SQL injection. I want to highlight a couple free, open source scanners you can start using now.

OWASP Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually. It acts as a web proxy that you point your browser to so it can see the traffic going to a site and allows you to spider, scan, fuzz, and attack the application. Here is ZAP finding the same SQLi vulnerability we found manually.

The Web Application Attack and Audit Framework (w3af) is an open-source web application security scanner and exploitation tool. w3af uses plugins to detect various security issues. After identification, w3af can be used to exploit them to gain access to the remote system. w3af has SQLi plugins that can find the vulnerability in web applications. Here is w3af finding the same SQLi vulnerability we found manually.

With all of the vulnerability scanners out there, it’s difficult to pick one worthy of your money. Shay-Chen compared 60 commercial and open source scanners based on a number of criteria. One of the tests included a head to head comparison of SQL Injection results. Here is how those scanners stack up in SQLi vulnerability detection.

Tools Used

ZAP – http://code.google.com/p/zaproxy/
w3af – http://w3af.sourceforge.net/
Mantra – http://getmantra.com/
OWASP Broken Web Apps – http://code.google.com/p/owaspbwa/
Backtrack – http://www.backtrack-linux.org/
Tamper Data – https://addons.mozilla.org/en-US/firefox/addon/tamper-data/
SQL Inject Me – https://addons.mozilla.org/en-US/firefox/addon/sql-inject-me/
The BodgeIt Store – http://code.google.com/p/bodgeit/
Damn Vulnerable Web Application – http://www.dvwa.co.uk/

Sources

https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)
http://sectooladdict.blogspot.com/2011/08/commercial-web-application-scanner.html
SQL Injection Attacks and Defense (Amazon) –

SQL, or structured query language, is a special purpose programming language designed for managing data in relational database management systems. It can be used to query, operate, and administer database systems such as MySQL, Microsoft SQL Server, and Oracle. These database systems are commonly used to provide backend functionality to many types of web applications.

In support of web applications, user supplied data is often used to dynamically build SQL statements that interact directly with a database. A SQL injection attack is an attack aimed at subverting the original intent of the application by submitting an attacker supplied SQL statement directly to the backend database.

Before I explain SQL injection further, let me describe how a basic web three tired web application might work.

Web Application Basics

Modern web applications provide compelling user experiences. They usually consist of a back-end database with web pages that contain server-side script written in a programming language that is capable of extracting specific information from a database depending on interactions with the user. A database driven application commonly has three tiers: presentation, logic, and storage.

• Presentation Tier: This tier displays information. It is typically a web browser, such as Internet Explorer, Safari, or Firefox.
• Logic Tier: This tier controls the application’s functionality by performing detailed processing. It is usually a programming language such as C#, ASP, .NET, PHP, or JSP.
• Storage Tier: This tier stores and retrieves information. It is usually a database such as Microsoft SQL Server, MySQL, or Oracle.

A user opens his web browser and connects to a website using the hypertext transfer protocol (http). The web server that resides in the logic tier loads a script from the file system and passes it through its scripting engine, where it is executed. The script opens a connection to the data tier and executes a SQL statement against he database. The database returns the data, which is passed to the scripting engine within the logic tier. The logic tier then implements any application or business logic rules before returning a web page in HTML format to the presentation tier. The user’s web browser renders the HTML and presents the user with a graphical user interface.

SQL Injection

A SQL injection attack involves the alteration of SQL statements that are used within a web application through the use of attacker supplied data. The primary form of SQL injection consists of direct insertion of code into parameters that are concatenated with SQL commands and executed.

Insufficient input validation and improper construction of SQL statements  in web applications can leave them vulnerable to SQL injection attacks. If an attacker can control the input that is sent to a SQL query and manipulate that input so that the data is interpreted as a code instead of as data, the attacker may be able to execute the code on the back-end database. Any procedure in the logic tier that constructs SQL statement could potentially be vulnerable.

Example

Let’s consider a vulnerable web application login form and login.php script:

Form

<form action=login.php method=post>
Username: <input type=text name=username />
Password: <input type=password name=password />
<input type=submit value=Login> </form>

login.php

//connect to database
$conn = mysql_connect(“localhost”, “username”, “password”);
//build sql statement
$query = “SELECT userid FROM AppUsers WHERE user= ‘$_POST[“username”]’ “ .
“AND password = ‘$_POST[“password”]’ “ ;
//run query
$result = mysql_query($query);
//ensure a user was returned
$numrows = mysql_num_rows($result);
if ($numrows != 0){
header(“Location: admin.php”);
}else{
die(‘Incorrect username or password.’)
}

If you login with the username “jsmith” and the password “kitteh” the application builds this SQL statement:

SELECT userid
FROM AppUsers
WHERE user = ‘jsmith’ AND password = ‘kitteh’ ;

In this case, as long as there is a record with the correct username and password, one row will be returned. Since the login script is looking for a query that returns any amount of rows other than 0, the login is successful.

But, if you inject simple SQL code with logic that results to true into the password field, such as “anything’ OR ‘1’ = ‘1” with the user “jsmith”, the application builds this SQL statement:

SELECT userid
FROM AppUsers
WHERE user = ‘jsmith’ AND password = ‘anything’ OR ‘1’ = ‘1’ ;

In this case, we changed the condition to something that will always be true, and all of the rows are returned. The number of rows is something other than 0, so the login is successful. This SQL injection attack allowed us to bypass the application’s authentication mechanism.

Impact of SQL Injection

As the example shows, SQL injection can allow us to bypass the authentication of a web application. It can also lead to accessing more data in the database that you have authorization to, changing or deleting that data, or even running arbitrary code on the database server potentially completely compromising it.

• Authentication Bypass: This attack allows an attacker to log on to an application without supplying a valid username and password.
• Information Disclosure: This attack allows an attacker to obtain sensitive information that is contained in a database.
• Alter Data: This attack involves the alteration of the contents of a database. This can be used to deface a web page. It can also be used to insert malicious content, like JavaScript malware.
• Delete Data: This attack allows an attacker to delete information with the intent to cause harm or delete log or audit information that is contained in a database.
• Remote Command Execution: Performing command execution through a database can allow an attacker to compromise the host operating system. These attacks often leverage an existing, predefined stored procedure for host operating system command execution.

How Prolific is the Issue?

According to the Web Application Security Consortium’s Web Hacking Incident Database, SQL injection is the most exploited website vulnerability.

While the latest WhiteHat Security Statistics Report agrees, it also ranks the SQL injection in the top 10 vulnerabilities asserting that 11% of websites found on the web are vulnerable.

 ”Welcome to DerbyCon 2.0 – “The Reunion”. This is the place where security professionals from all over the world come to hang out. DerbyCon 2.0 will be held September 27-30th, 2012. DerbyCon 2011 pulled in over 1,100 people with an amazing speaker lineup and a family-like feel. We’ve listened to your feedback and plan on making this conference even better. Our goal is to keep it around the same size and maintain a close-knit conference where we all come together to learn and share ideas.”

https://www.derbycon.com/

Check out the schedule; I’m presenting in the Stable Talks track!
https://www.derbycon.com/schedule/