OWASP - User contributions [en]

Category:OWASP Top Ten Project

2006-06-01T01:12:18Z

Samngms: /* Versions */

'''Welcome to the OWASP Top Ten Project'''

The OWASP Top Ten provides a minimum standard for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. There are currently versions in English, French, Japanese, and Korean. A Spanish version is in the works. We urge all companies to adopt the standard within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.

==Versions==

'''Browse online'''
* [[Commentary_OWASP_Top_Ten_Project|browse]]

'''Download'''
* [[Media:OWASP_Top_Ten_2004.doc|English (Word)]]
* [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=70827 English (PDF)]

'''[http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=70827 International Versions]'''
*Chinese
*English
*French
*Italian
*Japanese
*Spanish

==Top Ten Overview==

The following list summarizes the OWASP Top Ten. However, we strongly recommend reading the full report, as each area covers quite a lot of ground.

;[[Commentary OWASP Top Ten Project|Commentary]]
;[[Introduction_OWASP_Top_Ten_Project|Introduction]]
;[[Background OWASP Top Ten Project|Background]]
;[[Updates OWASP Top Ten Project|Updates]]

;A1 [[Unvalidated Input]]
:Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application.

;A2 [[Broken Access Control]]
:Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

;A3 [[Broken Authentication and Session Management]]
:Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.

;A4 [[Cross Site Scripting]]
:The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user?s session token, attack the local machine, or spoof content to fool the user.

;A5 [[Buffer Overflow]]
:Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

;A6 [[Injection Flaws]]
:Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

;A7 [[Improper Error Handling]]
:Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

;A8 [[Insecure Storage]]
:Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

;A9 [[Application Denial of Service]]
:Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.

;A10 [[Insecure Configuration Management]]
:Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.

;[[Conclusion OWASP Top Ten Project|Conclusion]]

==Acknowledgements==

OWASP would like to thank the researchers at Aspect Security for their leadership and contributions to the Top Ten project.

The OWASP Top Ten project lead is Jeff Williams from Aspect Security. He can be contacted at jeff.williams 'at' owasp.org.

International Translators

* Ludovic Petit (French)
* Satoru Takahashi (Japanese)
* Jeremy Bae (Korean)
* Juan Carlos Calderon,
* Pedro DelReal, Rogelio Morell and Javier Muzquiz (Spanish)

==Users and Adopters==

The U.S. Federal Trade Commission strongly recommends that all companies use the OWASP Top Ten and ensure that their partners do the same. In addition, the U.S. Defense Information Systems Agency has listed the OWASP Top Ten as key best practices that should be used as part of the DOD Information Technology Security Certification and Accreditation (C&A) Process (DITSCAP).

In the commercial market, the [http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf Payment Card Industry (PCI) standard] has adopted the OWASP Top Ten, and requires (among other things) that all merchants get a security code review for all their custom code. In addition, a broad range of companies and agencies around the globe are also using the OWASP Top Ten, including:

* Sprint
* IBM Global Services
* Cognizant
* Foundstone Strategic Security
* Bureau of Alcohol, Tobacco, and Firearms (ATF)
* Sun Microsystems
* British Telecom
* National Australia Bank
* Swiss Federal Institute of Technology
* Sempra Energy
* Corillian Corporation
* A.G. Edwards
* Texas Dept of Human Services
* Predictive Systems
* Price Waterhouse Coopers
* Best Software
* Online Business Systems
* ZipForm
* Contra Costa County, CA
* SSP Solutions
* Recreational Equipment, Inc. (REI)
* Zapatec
* Cboss Internet
* Samsung SDS (Korea)
* Norfolk Southern
* Bank of Newport
* ...and many others

Several schools have also adopted the OWASP Top Ten as a part of their curriculum, including Michigan State University (MSU), and the University of California at San Diego (UCSD).

==Feedback==

Please let us know how your organization is using the Top Ten. Include your name, organization's name, and brief description of how you use the list. Thanks for supporting OWASP!

We hope you find the information in the OWASP Top Ten useful. Please contribute back to the project by sending your comments, questions, and suggestions to topten@owasp.org. Thanks!

To join the OWASP Top Ten mailing list or view the archives, please visit the subscription page.

==Project Sponsors==

The OWASP Top Ten project is sponsored by
[http://www.aspectsecurity.com http://www.owasp.org/docroot/owasp/img/members/aspect_logo.gif]

[[Category:OWASP Project]]
[[Category:OWASP Document]]
[[Category:OWASP Download]]

Category:OWASP Top Ten Project

2006-06-01T01:05:02Z

Samngms: /* Versions */

'''Welcome to the OWASP Top Ten Project'''

The OWASP Top Ten provides a minimum standard for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. There are currently versions in English, French, Japanese, and Korean. A Spanish version is in the works. We urge all companies to adopt the standard within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.

==Versions==

'''Browse online'''
* [[Commentary_OWASP_Top_Ten_Project|browse]]

'''Download'''
* [[Media:OWASP_Top_Ten_2004.doc|English (Word)]]
* [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=70827 English (PDF)]

'''[http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=70827 International Versions]'''
*Chinese (Edit by Hong Kong Chapter)
*English
*French
*Italian
*Japanese
*Spanish

==Top Ten Overview==

The following list summarizes the OWASP Top Ten. However, we strongly recommend reading the full report, as each area covers quite a lot of ground.

;[[Commentary OWASP Top Ten Project|Commentary]]
;[[Introduction_OWASP_Top_Ten_Project|Introduction]]
;[[Background OWASP Top Ten Project|Background]]
;[[Updates OWASP Top Ten Project|Updates]]

;A1 [[Unvalidated Input]]
:Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application.

;A2 [[Broken Access Control]]
:Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

;A3 [[Broken Authentication and Session Management]]
:Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.

;A4 [[Cross Site Scripting]]
:The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user?s session token, attack the local machine, or spoof content to fool the user.

;A5 [[Buffer Overflow]]
:Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

;A6 [[Injection Flaws]]
:Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

;A7 [[Improper Error Handling]]
:Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

;A8 [[Insecure Storage]]
:Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

;A9 [[Application Denial of Service]]
:Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.

;A10 [[Insecure Configuration Management]]
:Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.

;[[Conclusion OWASP Top Ten Project|Conclusion]]

==Acknowledgements==

OWASP would like to thank the researchers at Aspect Security for their leadership and contributions to the Top Ten project.

The OWASP Top Ten project lead is Jeff Williams from Aspect Security. He can be contacted at jeff.williams 'at' owasp.org.

International Translators

* Ludovic Petit (French)
* Satoru Takahashi (Japanese)
* Jeremy Bae (Korean)
* Juan Carlos Calderon,
* Pedro DelReal, Rogelio Morell and Javier Muzquiz (Spanish)

==Users and Adopters==

The U.S. Federal Trade Commission strongly recommends that all companies use the OWASP Top Ten and ensure that their partners do the same. In addition, the U.S. Defense Information Systems Agency has listed the OWASP Top Ten as key best practices that should be used as part of the DOD Information Technology Security Certification and Accreditation (C&A) Process (DITSCAP).

In the commercial market, the [http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf Payment Card Industry (PCI) standard] has adopted the OWASP Top Ten, and requires (among other things) that all merchants get a security code review for all their custom code. In addition, a broad range of companies and agencies around the globe are also using the OWASP Top Ten, including:

* Sprint
* IBM Global Services
* Cognizant
* Foundstone Strategic Security
* Bureau of Alcohol, Tobacco, and Firearms (ATF)
* Sun Microsystems
* British Telecom
* National Australia Bank
* Swiss Federal Institute of Technology
* Sempra Energy
* Corillian Corporation
* A.G. Edwards
* Texas Dept of Human Services
* Predictive Systems
* Price Waterhouse Coopers
* Best Software
* Online Business Systems
* ZipForm
* Contra Costa County, CA
* SSP Solutions
* Recreational Equipment, Inc. (REI)
* Zapatec
* Cboss Internet
* Samsung SDS (Korea)
* Norfolk Southern
* Bank of Newport
* ...and many others

Several schools have also adopted the OWASP Top Ten as a part of their curriculum, including Michigan State University (MSU), and the University of California at San Diego (UCSD).

==Feedback==

Please let us know how your organization is using the Top Ten. Include your name, organization's name, and brief description of how you use the list. Thanks for supporting OWASP!

We hope you find the information in the OWASP Top Ten useful. Please contribute back to the project by sending your comments, questions, and suggestions to topten@owasp.org. Thanks!

To join the OWASP Top Ten mailing list or view the archives, please visit the subscription page.

==Project Sponsors==

The OWASP Top Ten project is sponsored by
[http://www.aspectsecurity.com http://www.owasp.org/docroot/owasp/img/members/aspect_logo.gif]

[[Category:OWASP Project]]
[[Category:OWASP Document]]
[[Category:OWASP Download]]

Category:OWASP Top Ten Project

2006-06-01T01:01:18Z

Samngms: /* Versions */

'''Welcome to the OWASP Top Ten Project'''

The OWASP Top Ten provides a minimum standard for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. There are currently versions in English, French, Japanese, and Korean. A Spanish version is in the works. We urge all companies to adopt the standard within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.

==Versions==

'''Browse online'''
* [[Commentary_OWASP_Top_Ten_Project|browse]]

'''Download'''
* [[Media:OWASP_Top_Ten_2004.doc|English (Word)]]
* [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=70827 English (PDF)]

'''[http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=70827 International Versions]'''
*Chinese (TC/SC)
*English
*French
*Italian
*Japanese
*Spanish

==Top Ten Overview==

The following list summarizes the OWASP Top Ten. However, we strongly recommend reading the full report, as each area covers quite a lot of ground.

;[[Commentary OWASP Top Ten Project|Commentary]]
;[[Introduction_OWASP_Top_Ten_Project|Introduction]]
;[[Background OWASP Top Ten Project|Background]]
;[[Updates OWASP Top Ten Project|Updates]]

;A1 [[Unvalidated Input]]
:Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application.

;A2 [[Broken Access Control]]
:Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

;A3 [[Broken Authentication and Session Management]]
:Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.

;A4 [[Cross Site Scripting]]
:The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user?s session token, attack the local machine, or spoof content to fool the user.

;A5 [[Buffer Overflow]]
:Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

;A6 [[Injection Flaws]]
:Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

;A7 [[Improper Error Handling]]
:Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

;A8 [[Insecure Storage]]
:Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

;A9 [[Application Denial of Service]]
:Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.

;A10 [[Insecure Configuration Management]]
:Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.

;[[Conclusion OWASP Top Ten Project|Conclusion]]

==Acknowledgements==

OWASP would like to thank the researchers at Aspect Security for their leadership and contributions to the Top Ten project.

The OWASP Top Ten project lead is Jeff Williams from Aspect Security. He can be contacted at jeff.williams 'at' owasp.org.

International Translators

* Ludovic Petit (French)
* Satoru Takahashi (Japanese)
* Jeremy Bae (Korean)
* Juan Carlos Calderon,
* Pedro DelReal, Rogelio Morell and Javier Muzquiz (Spanish)

==Users and Adopters==

The U.S. Federal Trade Commission strongly recommends that all companies use the OWASP Top Ten and ensure that their partners do the same. In addition, the U.S. Defense Information Systems Agency has listed the OWASP Top Ten as key best practices that should be used as part of the DOD Information Technology Security Certification and Accreditation (C&A) Process (DITSCAP).

In the commercial market, the [http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf Payment Card Industry (PCI) standard] has adopted the OWASP Top Ten, and requires (among other things) that all merchants get a security code review for all their custom code. In addition, a broad range of companies and agencies around the globe are also using the OWASP Top Ten, including:

* Sprint
* IBM Global Services
* Cognizant
* Foundstone Strategic Security
* Bureau of Alcohol, Tobacco, and Firearms (ATF)
* Sun Microsystems
* British Telecom
* National Australia Bank
* Swiss Federal Institute of Technology
* Sempra Energy
* Corillian Corporation
* A.G. Edwards
* Texas Dept of Human Services
* Predictive Systems
* Price Waterhouse Coopers
* Best Software
* Online Business Systems
* ZipForm
* Contra Costa County, CA
* SSP Solutions
* Recreational Equipment, Inc. (REI)
* Zapatec
* Cboss Internet
* Samsung SDS (Korea)
* Norfolk Southern
* Bank of Newport
* ...and many others

Several schools have also adopted the OWASP Top Ten as a part of their curriculum, including Michigan State University (MSU), and the University of California at San Diego (UCSD).

==Feedback==

Please let us know how your organization is using the Top Ten. Include your name, organization's name, and brief description of how you use the list. Thanks for supporting OWASP!

We hope you find the information in the OWASP Top Ten useful. Please contribute back to the project by sending your comments, questions, and suggestions to topten@owasp.org. Thanks!

To join the OWASP Top Ten mailing list or view the archives, please visit the subscription page.

==Project Sponsors==

The OWASP Top Ten project is sponsored by
[http://www.aspectsecurity.com http://www.owasp.org/docroot/owasp/img/members/aspect_logo.gif]

[[Category:OWASP Project]]
[[Category:OWASP Document]]
[[Category:OWASP Download]]

Category:Attack

2006-05-31T01:35:11Z

Samngms: /* Work to be done here includes */

'''Application Security Threats'''

This category is for common types of application security attacks. These are the techniques that attackers use to exploit the vulnerabilities in applications. Attacks are often confused with vulnerabilities, so please try to be sure that the attack you are describing is something that an attacker would do, rather than a weakness in an application.

An attack article should include:
* the [[:Category:Threat|Threat]]
* the [[:Category:Vulnerability|Vulnerability]]
* a description of exactly how the attack works
* tools and techniques for performing the attack

{{Template:PutInCategory}}

{{Template:Stub}}

==Work to be done here includes==

Creating articles for the following topics:
*Brute Force Attacks
*Account Lockout
*Credential/Session Prediction
*Unauthorized Access Attempts
*Session Fixation
*Session Hijacking
*Cross-Site Scripting
*Buffer Overflow Attack
*Format String Attack
*Directory Indexing
*File Path Abuse
*Traffic Flood
*Automation of Functionality
*File location guessing (see [[Guessed or visible temporary file]]
* ... make sure the attack is listed for each [[:Category:Vulnerability|vulnerability]]

Note: many of the items marked vulnerabilities from CLASP and other places are really attacks. Some of the more obvious are:
* [[Command injection]]
* [[Log injection]]
* [[Resource exhaustion]]
* [[SQL injection]]
* [[Reflection injection]]
* [[Reflection attack in an auth protocol]]

[[Category:Article Type]]

SQL Injection

2006-05-31T01:34:50Z

Samngms: /* Avoidance and mitigation */

{{Template:SecureSoftware}}

==Overview==

[[Glossary#SQL Injection|SQL Injection]] attacks are another instantiation of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

==Consequences ==

* Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with [[Glossary#SQL Injection|SQL Injection]] vulnerabilities.

* Authentication: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.

* Authorization: If authorization information is held in an SQL database, it may be possible to change this information through the successful exploitation of an [[Glossary#SQL Injection|SQL Injection]] vulnerability.

* Integrity: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with an [[Glossary#SQL Injection|SQL Injection]] attack.

==Exposure period ==

* Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen.

* Implementation: If SQL is used, all flaws resulting in [[Glossary#SQL Injection|SQL Injection]] problems must be mitigated at the implementation level.

==Platform ==

* Language: SQL

* Platform: Any (requires interaction with an SQL database)

==Required resources ==

Any

==Severity ==

Medium to High

==Likelihood of exploit ==

Very High

==Avoidance and mitigation ==

* Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen.

* Implementation: Use vigorous white-list style checking on any user input that may be used in an SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that has been entered in the database may neglect to escape meta-characters before use.

* [[Image:Advanced Topics on SQL Injection Protection.ppt]]

==Discussion ==

[[Glossary#SQL Injection|SQL Injection]] has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind.

Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

==Examples ==

In SQL:

<pre>
select id, firstname, lastname from authors
</pre>

If one provided:

<pre>
Firstname: evil'ex
Lastname: Newman
</pre>

the query string becomes:

<pre>
select id, firstname, lastname from authors where forename = 'evil'ex' and surname ='newman'
which the database attempts to run as
</pre>

<pre>
Incorrect syntax near al' as the database tried to execute evil.
</pre>

A safe version of the above SQL statement could be coded in Java as:

<pre>
String firstname = req.getParameter("firstname");
String lastname = req.getParameter("lastname");
// FIXME: do your own validation to detect attacks
String query = "SELECT id, firstname, lastname FROM authors WHERE forename = ? and surname = ?";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, firstname );
pstmt.setString( 2, lastname );
try
{
ResultSet results = pstmt.execute( );
}
</pre>

==Related problems ==

* [[Injection problem]]

[[Category:Vulnerability]]

[[Category:Range and Type Errors]]

[[Category:OWASP_CLASP_Project]]

[[Category:Code Snippet]]

[[Category:Java]]

SQL Injection

2006-05-31T01:34:14Z

Samngms: /* Avoidance and mitigation */

{{Template:SecureSoftware}}

==Overview==

[[Glossary#SQL Injection|SQL Injection]] attacks are another instantiation of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

==Consequences ==

* Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with [[Glossary#SQL Injection|SQL Injection]] vulnerabilities.

* Authentication: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.

* Authorization: If authorization information is held in an SQL database, it may be possible to change this information through the successful exploitation of an [[Glossary#SQL Injection|SQL Injection]] vulnerability.

* Integrity: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with an [[Glossary#SQL Injection|SQL Injection]] attack.

==Exposure period ==

* Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen.

* Implementation: If SQL is used, all flaws resulting in [[Glossary#SQL Injection|SQL Injection]] problems must be mitigated at the implementation level.

==Platform ==

* Language: SQL

* Platform: Any (requires interaction with an SQL database)

==Required resources ==

Any

==Severity ==

Medium to High

==Likelihood of exploit ==

Very High

==Avoidance and mitigation ==

* Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen.

* Implementation: Use vigorous white-list style checking on any user input that may be used in an SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that has been entered in the database may neglect to escape meta-characters before use.

* [[Image:Advanced Topics on SQL Injection Protection.ppt|Advanced Topics on SQL Injection Protection]]

==Discussion ==

[[Glossary#SQL Injection|SQL Injection]] has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind.

Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

==Examples ==

In SQL:

<pre>
select id, firstname, lastname from authors
</pre>

If one provided:

<pre>
Firstname: evil'ex
Lastname: Newman
</pre>

the query string becomes:

<pre>
select id, firstname, lastname from authors where forename = 'evil'ex' and surname ='newman'
which the database attempts to run as
</pre>

<pre>
Incorrect syntax near al' as the database tried to execute evil.
</pre>

A safe version of the above SQL statement could be coded in Java as:

<pre>
String firstname = req.getParameter("firstname");
String lastname = req.getParameter("lastname");
// FIXME: do your own validation to detect attacks
String query = "SELECT id, firstname, lastname FROM authors WHERE forename = ? and surname = ?";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, firstname );
pstmt.setString( 2, lastname );
try
{
ResultSet results = pstmt.execute( );
}
</pre>

==Related problems ==

* [[Injection problem]]

[[Category:Vulnerability]]

[[Category:Range and Type Errors]]

[[Category:OWASP_CLASP_Project]]

[[Category:Code Snippet]]

[[Category:Java]]

Category:Attack

2006-05-31T01:32:02Z

Samngms: /* Work to be done here includes */

'''Application Security Threats'''

This category is for common types of application security attacks. These are the techniques that attackers use to exploit the vulnerabilities in applications. Attacks are often confused with vulnerabilities, so please try to be sure that the attack you are describing is something that an attacker would do, rather than a weakness in an application.

An attack article should include:
* the [[:Category:Threat|Threat]]
* the [[:Category:Vulnerability|Vulnerability]]
* a description of exactly how the attack works
* tools and techniques for performing the attack

{{Template:PutInCategory}}

{{Template:Stub}}

==Work to be done here includes==

Creating articles for the following topics:
*Brute Force Attacks
*Account Lockout
*Credential/Session Prediction
*Unauthorized Access Attempts
*Session Fixation
*Session Hijacking
*Cross-Site Scripting
*Buffer Overflow Attack
*Format String Attack
*Directory Indexing
*File Path Abuse
*Traffic Flood
*Automation of Functionality
*File location guessing (see [[Guessed or visible temporary file]]
* ... make sure the attack is listed for each [[:Category:Vulnerability|vulnerability]]

Note: many of the items marked vulnerabilities from CLASP and other places are really attacks. Some of the more obvious are:
* [[Command injection]]
* [[Log injection]]
* [[Resource exhaustion]]
* [[SQL injection]]
* [[Image:Advanced Topics on SQL Injection Protection.ppt]]
* [[Reflection injection]]
* [[Reflection attack in an auth protocol]]

[[Category:Article Type]]

File:Advanced Topics on SQL Injection Protection.ppt

2006-05-31T01:29:17Z

Samngms: 7 methods to prevent SQL injection attacks correctly and in a more integrated approach. Methods 1 to 3 are applicable during design or development life cycle. Method 4 is mainly from QA’s perspective. Methods 5 and 6 can be applied to production environ

7 methods to prevent SQL injection attacks correctly and in a more integrated approach. Methods 1 to 3 are applicable during design or development life cycle. Method 4 is mainly from QA’s perspective. Methods 5 and 6 can be applied to production environment and are applicable even if you do not have access to or if you cannot change the source code. Other non-main stream technology are discussed in Method 7.