https://wiki.owasp.org/api.php?action=feedcontributions&user=Fmavituna&feedformat=atomOWASP - User contributions [en]2024-03-29T11:21:13ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=Advertising&diff=71552Advertising2009-10-15T17:11:07Z<p>Fmavituna: </p>
<hr />
<div>==Advertising at OWASP==<br />
<br />
==Audience==<br />
<br />
The owasp.org web site gets [http://www.alexa.com/siteinfo/owasp.org+us-cert.gov+sans.org+webappsec.org more traffic] than most websites. OWASP is dedicated to securing software applications and mainly attracts developers, system architects, project managers, and security specialists who are working in the field or looking to understand more about the topic.<br />
<br />
We value all who visit our site and while we need to sell advertising to maintain our site, we are respectful of our readers. We will never sell or give away our registration lists under any circumstances.<br />
<br />
<alexafeed/><br />
<br />
OWASP offers a 468x60 banner ad space on the home page and local chapter pages. We allow up to a maximum of 3 advertisers to purchase a spot in the rotation.<br />
<br />
OWASP adopts the following policy.<br />
<br />
* The OWASP Board of Directors reserves the right to refuse any advert for any reason by vote.<br />
* All adverts will be marked as Paid Advertisements<br />
* All banner adverts must be no more than 468 x 60 pixels and use no more than 256 colors<br />
* All banner adverts must not simulate flashing text or images<br />
* All banner adverts must use no more than three rotating images (gif) which must not rotate more frequently than 5 seconds per image<br />
<br />
==Current Rates==<br />
<br />
A banner advertisement on the top of the main page:<br />
<br />
2009 - $2,500 USD per month<br />
<br />
Another great way to get your message out is to sponsor a particular project. Please contact owasp@owasp.org to discuss your idea.<br />
<br />
==Available Slots==<br />
<br />
Available slots may change without notice. Please contact us to confirm the dates below.<br />
<br />
<br />
We are currently filling slots for the year 2009<br />
<br />
{| border=1 <br />
||'''Start Date''' ||'''End Date''' ||'''Status''' <br />
|-<br />
||January 1, 2009||January 31, 2009 || <span style="color:green">Closed</span><br />
|- <br />
||February 1, 2009||February 28, 2009 || <span style="color:green">Closed</span><br />
|-<br />
||March 1, 2009||March 31, 2009 || <span style="color:green">Closed</span><br />
|-<br />
||April 1, 2009||April 30, 2009 || <span style="color:green">Closed</span><br />
|-<br />
||May 1, 2009||May 31, 2009 || <span style="color:green">Closed</span><br />
|-<br />
||June 1, 2009||June 30, 2009 || <span style="color:green">Closed</span><br />
|-<br />
||July 1, 2009||July 31, 2009 || <span style="color:green">Closed</span><br />
|-<br />
||August 1, 2009|| August 31, 2009 || <span style="color:green">Closed</span><br />
|-<br />
||September 1, 2009|| September 30, 2009 || <span style="color:green">Closed</span><br />
|-<br />
||October 1, 2009|| October 31, 2009 || <span style="color:green">Closed</span><br />
|-<br />
||November 1, 2009|| November 30, 2009 || <span style="color:green">Available</span><br />
|-<br />
||December 1, 2009|| December 31, 2009 ||<span style="color:green">Available</span><br />
|-<br />
|}<br />
<br />
<br />
==Contact==<br />
<br />
Please contact us at [mailto:kate.hartmann@owasp.org kate.hartmann@owasp.org] to inquire about advertising at OWASP.<br />
<br />
[[About_The_Open_Web_Application_Security_Project]]</div>Fmavitunahttps://wiki.owasp.org/index.php?title=One_Click_Ownage&diff=71334One Click Ownage2009-10-11T13:08:19Z<p>Fmavituna: /* The speaker */</p>
<hr />
<div>== The presentation ==<br />
<br />
[[Image:Owasp_logo_normal.jpg|right]]A simple plug-in based open source framework for Automation of detection and exploitation vulnerabilities such as SQL Injection, Arbitrary File Upload and Remote Code Execution. Talks demonstrates how to gain a remote shell in an SQL Injection just by one request. Also it shows that it's possible to get a reverse shell out of SQL Injection by mounting a CSRF attack which wasn't possible before this. WebRaider is written in .NET, open-source and allows users to write new attack plug-ins. It's a similar design to CORE Impact just for web applications and vulnerabilites which causes remote code execution. It's planned to be an OWASP Project, and will be publicly released in the conference among with "One Click Ownage" whitepaper which explains one request remote code execution in SQL Server. This will be an updated and more detailed version of the talk that I've presented in ITUnderground 2009. However the whitepaper, WebRaider tool and details of the talk hasn't been published yet.<br />
<br />
== The speaker ==<br />
<br />
Ferruh Mavituna worked as Security Consultant for Turkish Army and Police Forces. Released several research papers such as "SQL Injection Wildcard Attacks" and "XSS Tunnelling" also contributed to OWASP Testing Guide v3. Released several open source projects in web applications area such as "BSQL Hacker" and "XSS Shell". Was OWASP Turkey Chapter Leader for 3 years. He's currently working as Project Leader of "Netsparker, Web Application Security Scanner" for Mavituna Security Ltd.<br />
<br />
[[Category:OWASP_AppSec_DC_09]] [[Category:OWASP_Conference_Presentations]]</div>Fmavitunahttps://wiki.owasp.org/index.php?title=One_Click_Ownage&diff=68133One Click Ownage2009-08-28T00:34:25Z<p>Fmavituna: </p>
<hr />
<div>== The presentation ==<br />
<br />
[[Image:Owasp_logo_normal.jpg|right]]A simple plug-in based open source framework for Automation of detection and exploitation vulnerabilities such as SQL Injection, Arbitrary File Upload and Remote Code Execution. Talks demonstrates how to gain a remote shell in an SQL Injection just by one request. Also it shows that it's possible to get a reverse shell out of SQL Injection by mounting a CSRF attack which wasn't possible before this. WebRaider is written in .NET, open-source and allows users to write new attack plug-ins. It's a similar design to CORE Impact just for web applications and vulnerabilites which causes remote code execution. It's planned to be an OWASP Project, and will be publicly released in the conference among with "One Click Ownage" whitepaper which explains one request remote code execution in SQL Server. This will be an updated and more detailed version of the talk that I've presented in ITUnderground 2009. However the whitepaper, WebRaider tool and details of the talk hasn't been published yet.<br />
<br />
== The speaker ==<br />
<br />
Ferruh Mavituna worked as Security Consultant for Turkish Army and Police Forces. Released several research papers such as "SQL Injection Wildcard Attacks" and "XSS Tunnelling" also contributed to OWASP Testing Guide v3. Released several open source projects in web applications area such as "BSQL Hacker" and "XSS Shell". Was OWASP Turkey Chapter Leader for 3 years. He's currently working for Mavituna Security Ltd.<br />
<br />
[[Category:OWASP_AppSec_DC_09]] [[Category:OWASP_Conference_Presentations]]</div>Fmavitunahttps://wiki.owasp.org/index.php?title=SQL_Injection_Prevention_Cheat_Sheet&diff=57910SQL Injection Prevention Cheat Sheet2009-04-03T15:51:18Z<p>Fmavituna: /* Related Articles */</p>
<hr />
<div>= Introduction =<br />
<br />
[[SQL Injection]] attacks are unfortunately very common, and this is due to two factors:<br />
<br />
# the significant prevalence of SQL Injection vulnerabilities, and <br />
# the attractiveness of the target (i.e., the database typically contains all the interesting/critical data for your application).<br />
<br />
It’s somewhat shameful that there are so many successful SQL Injection attacks occurring, because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.<br />
<br />
SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input. To avoid SQL injection flaws is simple. Developers need to either:<br />
a) stop writing dynamic queries; and/or<br />
b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query.<br />
<br />
This article provides a set of simple techniques for preventing SQL Injection vulnerabilities by avoiding these two problems. These techniques can be used with practically any kind of programming language with any type of database. There are other types of databases, like XML databases, which can have similar problems (e.g., XPath and XQuery injection) and these techniques can be used to protect them as well.<br />
<br />
Primary Defenses:<br />
* '''Option #1: Use of Prepared Statements (Parameterized Queries)'''<br />
* '''Option #2: Use of Stored Procedures'''<br />
* '''Option #3: Escaping all User Supplied Input'''<br />
<br />
Additional Defenses:<br />
* '''Also Enforce: Least Privilege'''<br />
* '''Also Perform: White List Input Validation'''<br />
<br><br />
;Unsafe Example<br />
<br />
SQL injection flaws typically look like this:<br />
<br />
The following (Java) example is UNSAFE, and would allow an attacker to inject code into the query that would be executed by the database. The unvalidated “customerName” parameter that is simply appended to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing databases is all too common.<br />
<br />
String query = "SELECT account_balance FROM user_data WHERE user_name = "<br />
+ request.getParameter("customerName");<br />
<br />
try {<br />
Statement statement = connection.createStatement( … );<br />
ResultSet results = statement.executeQuery( query );<br />
}<br />
<br />
=Primary Defenses=<br />
<br />
==Defense Option 1: Prepared Statements (Parameterized Queries)==<br />
<br />
The use of prepared statements (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.<br />
<br />
Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the safe example below, if an attacker were to enter the userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1.<br />
<br />
In rare circumstances, prepared statements can harm performance. When confronted with this situation, it is best to escape all user supplied input using an escaping routine specific to your database vendor as is described below, rather than using a prepared statement. Another option which might solve your performance issue is used a stored procedure instead.<br />
<br />
;Safe Java Prepared Statement Example <br />
<br />
The following code example uses a PreparedStatement, Java's implementation of a parameterized query, to execute the same database query.<br />
<br />
String custname = request.getParameter("customerName"); // This should REALLY be validated too<br />
// perform input validation to detect attacks<br />
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";<br />
<br />
'''PreparedStatement pstmt = connection.prepareStatement( query );'''<br />
'''pstmt.setString( 1, custname); '''<br />
ResultSet results = pstmt.executeQuery( );<br />
<br />
;Safe C# .NET Prepared Statement Example <br />
<br />
With .NET, it's even more straightforward. The creation and execution of the query doesn't change. All you have to do is simply pass the parameters to the query using the Parameters.Add() call as shown here.<br />
<br />
String query = <br />
"SELECT account_balance FROM user_data WHERE user_name = ?";<br />
try {<br />
OleDbCommand command = new OleDbCommand(query, connection);<br />
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''<br />
OleDbDataReader reader = command.ExecuteReader();<br />
// …<br />
} catch (OleDbException se) {<br />
// error handling<br />
} <br />
<br />
We have shown examples in Java and .NET but practically all other languages, including Cold Fusion, and Classic ASP, support parameterized query interfaces.<br />
<br />
Developers tend to like the Prepared Statement approach because all the SQL code stays within the application. This makes your application relatively database independent. However, other options allow you to store all the SQL code in the database itself, which has both security and non-security advantages. That approach, called Stored Procedures, is described next.<br />
<br />
==Defense Option 2: Stored Procedures==<br />
<br />
Stored procedures have the same effect as the use of prepared statements when implemented safely*. They require the developer to define the SQL code first, and then pass in the parameters after. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.<br />
<br />
&#42;Note: 'Implemented safely' means the stored procedure does not include any unsafe dynamic SQL generation. Developers do not usually generate dynamic SQL inside stored procedures. However, it can be done, but should be avoided. If it can't be avoided, the stored procedure must use input validation or proper escaping as described in this article to make sure that all user supplied input to the stored procedure can't be used to inject SQL code into the dynamically generated query.<br />
<br />
;Safe Java Stored Procedure Example<br />
<br />
The following code example uses a CallableStatement, Java's implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.<br />
<br />
String custname = request.getParameter("customerName "); // This should REALLY be validated<br />
try {<br />
'''CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");'''<br />
'''cs.setString(1, custname);'''<br />
ResultSet results = cs.executeQuery(); <br />
// … result set handling <br />
} catch (SQLException se) { <br />
// … logging and error handling<br />
}<br />
<br />
;Safe VB .NET Stored Procedure Example <br />
<br />
The following code example uses a SqlCommand, .NET’s implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.<br />
<br />
Try<br />
Dim command As SqlCommand = new SqlCommand("sp_getAccountBalance", connection)<br />
'''command.CommandType = CommandType.StoredProcedure'''<br />
'''command.Parameters.Add(new SqlParameter("@CustomerName", CustomerName.Text))'''<br />
Dim reader As SqlDataReader = command.ExecuteReader()<br />
‘ …<br />
Catch se As SqlException <br />
‘ error handling<br />
End Try<br />
<br />
We have shown examples in Java and .NET but practically all other languages, including Cold Fusion, and Classic ASP, support the ability to invoke stored procedures.<br />
<br />
For organizations that already make significant or even exclusive use of stored procedures, it is far less likely that they have SQL injection flaws in the first place. However, you still need to be careful with stored procedures because it is possible, although relatively rare, to create a dynamic query inside of a stored procedure that is subject to SQL injection. If dynamic queries in your stored procedures can’t be avoided, then validate or properly escape all user supplied input to the dynamic query, before you construct it.<br />
<br />
There are also some additional security and non-security benefits of stored procedures that are worth considering. One security benefit is that if you make exclusive use of stored procedures for your database, you can restrict all database user accounts to only have access to the stored procedures. This means that database accounts do not have permission to submit dynamic queries to the database, giving you far greater confidence that you do not have any SQL injection vulnerabilities in the applications that access that database. Some non-security benefits include performance benefits (in most situations), and having all the SQL code in one location, potentially simplifying maintenance of the code and keeping the SQL code out of the application developers' hands, leaving it for the database developers to develop and maintain.<br />
<br />
==Defense Option 3: Escaping all User Supplied Input==<br />
<br />
This third technique is an approach being advocated by [[User:Jeff Williams|Jeff Williams]], who is the lead for OWASP's [[ESAPI]] project. It has the advantage that you can apply it to an existing application with almost no affect on the structure of the code. If you are concerned that rewriting your dynamic queries as prepared statements or stored procedures might break your application or adversely affect performance, then this might be the best approach for you.<br />
<br />
This technique works like this. Each DBMS supports a character escaping scheme were you can escape special characters in order to indicate to the DBMS that the characters you are providing in the query are intended to be data, and not code. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.<br />
<br />
To perform this escaping, you need to understand the escaping scheme supported by the DBMS you are using, and write an escaping routine, or you can use one of the existing database escaping routines provided by the OWASP ESAPI project. The ESAPI database encoders (escaping routines) were developed by reviewing the specs for Oracle and MySQL to understand what their escaping scheme is.<br />
<br />
* Full details on [[ESAPI|ESAPI are available here on OWASP]].<br />
* The javadoc for [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html ESAPI is available here at its Google Code repository].<br />
* You can also directly [http://code.google.com/p/owasp-esapi-java/source/browse/#svn/trunk/src/main/java/org/owasp/esapi browse the source at Google], which is frequently helpful if the javadoc isn't perfectly clear.<br />
<br />
To find the javadoc specifically for the database encoders, click on the ‘Codec’ class on the left hand side. There are lots of Codecs implemented. The two Database specific codecs are OracleCodec, and MySQLCodec.<br />
<br />
Just click on their names in the ‘All Known Implementing Classes:’ at the top of the Interface Codec page.<br />
<br />
To use an ESAPI database codec is pretty simple. An Oracle example looks something like:<br />
ESAPI.encodeForSQL( new OracleCodec(), queryparam );<br />
<br />
So, if you had an existing Dynamic query being generated in your code that was going to Oracle that looked like this:<br />
<br />
String query = "SELECT user_id FROM user_data WHERE user_name = '" + req.getParameter("userID") <br />
+ "' and user_password = '" + req.getParameter("pwd") +"'";<br />
try {<br />
Statement statement = connection.createStatement( … );<br />
ResultSet results = statement.executeQuery( query );<br />
}<br />
<br />
You would rewrite the first line to look like this:<br />
<br />
'''Codec ORACLE_CODEC = new OracleCodec();'''<br />
String query = "SELECT user_id FROM user_data WHERE user_name = '" + <br />
'''ESAPI.encodeForSQL( ORACLE_CODEC, req.getParameter("userID"))''' + "' and user_password = '"<br />
+ '''ESAPI.encodeForSQL( ORACLE_CODEC, req.getParameter("pwd"))''' +"'";<br />
<br />
And it would now be safe from SQL injection, regardless of the input supplied.<br />
<br />
If you created a wrapper method called ESAPI.encodeForOracle( param ) so you didn’t have to pass the Oracle codec in each time, then it would be even simpler and look like:<br />
<br />
String query = "SELECT user_id FROM user_data WHERE user_name = '" <br />
+ '''ESAPI.encodeForOracle( req.getParameter("userID"))''' + "' and user_password = '" <br />
+ '''ESAPI.encodeForOracle( req.getParameter("pwd"))''' +"'";<br />
<br />
With this type of solution, all your developers would have to do is wrap each user supplied parameter being passed in into an '''ESAPI.encodeForOracle( )''' call or whatever you named it, and you would be done.<br />
<br />
At this time, ESAPI currently has database encoders for:<br />
* Oracle<br />
* MySQL (Both ANSI and native modes are supported)<br />
<br />
Database encoders for:<br />
* SQL Server<br />
* PostgreSQL<br />
<br />
Are forthcoming. If your database encoder is missing, please let us know.<br />
<br />
===Database Specific Escaping Details===<br />
<br />
If you want to build your own escaping routines, here are the escaping details for each of the databases that we have developed ESAPI Encoders for:<br />
<br />
====Oracle Escaping====<br />
Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the \c format where 'c' is the original non-alphanumeric character.<br />
<br />
An alternative is to place { and } around the string to escape the entire string. However, you have to be careful that there isn't a } character already in the string. You must search for these and if there is one, then you must replace it with }}. Otherwise that character will end the escaping early, and may introduce a vulnerability.<br />
<br />
This information is based on the Oracle Escape character information found here: http://download-uk.oracle.com/docs/cd/B10501_01/text.920/a96518/cqspcl.htm<br />
<br />
====MySQL Escaping====<br />
<br />
MySQL supports two escaping modes:<br />
<br />
# ANSI_QUOTES SQL mode, and a mode with this off, which we call<br />
# MySQL mode.<br />
<br />
ANSI SQL mode: Simply encode all ' (single tick) characters with '&#39; (two single ticks)<br />
<br />
MySQL mode: Do the following:<br />
<br />
NUL (0x00) --> \0 [This is a zero, not the letter O]<br />
BS (0x08) --> \b<br />
TAB (0x09) --> \t<br />
LF (0x0a) --> \n<br />
CR (0x0d) --> \r<br />
SUB (0x1a) --> \z<br />
" (0x22) --> \"<br />
% (0x25) --> \%<br />
' (0x27) --> \'<br />
\ (0x5c) --> \"<br />
_ (0x5f) --> \_ <br />
all other non-alphanumeric characters with ASCII values less than 256 --> \c<br />
where 'c' is the original non-alphanumeric character<br />
<br />
This information is based on the MySQL Escape character information found here: http://mirror.yandex.ru/mirrors/ftp.mysql.com/doc/refman/5.0/en/string-syntax.html<br />
<br />
= Additional Defenses =<br />
<br />
Beyond adopting one of the three primary defenses, we also recommend adopting all of these additional defenses in order to provide defense in depth. These additional defenses are:<br />
<br />
* '''Least Privilege'''<br />
* '''White List Input Validation'''<br />
<br />
== Least Privilege ==<br />
<br />
To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is easy, and everything just ‘works’ when you do it this way, but it is very dangerous. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.<br />
<br />
If you adopt a policy where you use stored procedures everywhere, and don’t allow application accounts to directly execute their own queries, then restrict those accounts to only be able to execute the stored procedures they need. Don’t grant them any rights directly to the tables in the database.<br />
<br />
SQL injection is not the only threat to your database data. Attackers can simply change the parameter values from one of the legal values they are presented with, to a value that is unauthorized for them, but the application itself might be authorized to access. As such, minimizing the privileges granted to your application will reduce the likelihood of such unauthorized access attempts, even when an attacker is not trying to use SQL injection as part of their exploit.<br />
<br />
While you are at it, you should minimize the privileges of the operating system account that the DBMS runs under. Don't run your DBMS as root or system! Most DBMSs run out of the box with a very powerful system account. For example, MySQL runs as system on Windows by default! Change the DBMS's OS account to something more appropriate, with restricted privileges.<br />
<br />
== White List Input Validation ==<br />
<br />
It is always recommended to prevent attacks as early as possible in the processing of the user’s (attacker's) request. Input validation can be used to detect unauthorized input before it is passed to the SQL query. Developers frequently perform black list validation in order to try to detect attack characters and patterns like the ' character or the string 1=1, but this is a massively flawed approach as it is typically trivial for an attacker to avoid getting caught by such filters. Plus, such filters frequently prevent authorized input, like O'Brian, when the ' character is being filtered out.<br />
<br />
White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place. The most difficult fields to validate are so called 'free text' fields, like blog entries. However, even those types of fields can be validated to some degree, you can at least exclude all non-printable characters, and define a maximum size for the input field.<br />
<br />
Developing regular expressions can be complicated, and is well beyond the scope of this cheat sheet. There are lots of resources on the internet about how to write regular expressions, including: [http://www.regular-expressions.info/ http://www.regular-expressions.info/]. The following provides a few examples of ‘white list’ style regular expressions:<br />
<br />
White List Regex Examples<br />
Validating Data from Free Form Text Field for Zip Code (5 digits plus optional -4) ^\d{5}(-\d{4})?$<br />
<br />
Validating Data from Fixed List Drop-Down Box For U.S. State Selection<br />
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|<br />
MO|MT|NE|NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|TX|UT|VT|VI|VA|WA|WV|WI|WY)$<br />
<br />
Validating a Free Form Text Field for allowed chars (numbers, letters, whitespace, .-_)<br />
^[a-zA-Z0-9\s\.\-_]+$ (Any number of characters)<br />
^[a-zA-Z0-9\s\.\-_]{1-100}$ (This is better, since it limits this field to 1 to 100 characters)<br />
Note: \s matches any whitespace character (i.e., space, tab, carriage return, or linefeed, [ \t\r\n])<br />
<br />
Additional Examples are available at the [[OWASP Validation Regex Repository]]<br />
<br />
'''Java Regex Usage Example'''<br />
<br />
Example validating the parameter “zip” using a regular expression.<br />
<br />
private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");<br />
public void doPost( HttpServletRequest request, HttpServletResponse response) {<br />
try {<br />
String zipCode = request.getParameter( "zip" );<br />
if ( !zipPattern.matcher( zipCode ).matches() {<br />
throw new YourValidationException( "Improper zipcode format." );<br />
}<br />
.. do what you want here, after its been validated ..<br />
} catch(YourValidationException e ) {<br />
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );<br />
}<br />
}<br />
<br />
Some white list validators have also been predefined in various open source packages that you can leverage. Two packages that provide this are:<br />
* [http://jakarta.apache.org/commons/validator Apache Commons Validator]<br />
* [[ESAPI | OWASP ESAPI Validators]]<br />
It is strongly recommended that you use ESAPI to assist with your input validation needs, rather than writing your own validation routines. The [[ESAPI | OWASP Enterprise Security API (ESAPI)]] project has predefined validators defined in the org.owasp.esapi.Validator interface and implemented in the DefaultValidator reference implementation. These include:<br />
* getValidDate()<br />
* getValidCreditCard()<br />
* getValidSafeHTML()<br />
* getValidInput()<br />
* getValidNumber()<br />
* getValidFileName()<br />
* getValidRedirectLocation()<br />
<br />
With ESAPI, the previous example can be rewritten as follows:<br />
<br />
Example validating the parameter “zip” with generic ESAPI input validator.<br />
<br />
public void doPost( HttpServletRequest request, HttpServletResponse response) {<br />
try {<br />
String zipCode = '''Validator.getValidInput("ChangeAddressPage_ZipCodeField", <br />
request.getParameter( "zip" ), "zipCodePattern", 10, false))''';<br />
.. do what you want with validated ‘zipCode’ param here ..<br />
} catch( ValidationException e ) {<br />
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );<br />
}<br />
}<br />
<br />
// zipCodePattern is the name of a property defined in ESAPI.properties, and its value<br />
// is the regular expression: "^\d{5}(-\d{4})?$"<br />
// <br />
// If zipcodes were a frequently used parameter in your application, we would recommend <br />
// that you create your own getValidZipCode() method that builds on top of ESAPI, to make <br />
// it even simpler for your developers to use.<br />
<br />
* The overall [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html javadoc for ESAPI is here]<br />
* And the [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/Validator.html javadoc for this specific interface is here].<br />
<br />
=Related Articles=<br />
<br />
'''SQL Injection Attack Cheat Sheet'''<br />
<br />
The following article describes how to exploit different kinds of SQL Injection Vulnerabilities on various platforms that this article was created to help you avoid:<br />
<br />
* Michael Daw : "SQL Injection Cheat Sheet" - http://michaeldaw.org/sql-injection-cheat-sheet/<br />
* Ferruh Mavituna : "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/<br />
<br />
'''Description of SQL Injection Vulnerabilities'''<br />
<br />
* OWASP article on [[SQL Injection]] Vulnerabilities<br />
* OWASP article on [[Blind_SQL_Injection]] Vulnerabilities<br />
<br />
'''How to Avoid SQL Injection Vulnerabilities'''<br />
<br />
* [[:Category:OWASP Guide Project|OWASP Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities<br />
* OWASP article on [[Preventing SQL Injection in Java]]<br />
<br />
'''How to Review Code for SQL Injection Vulnerabilities'''<br />
<br />
* [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities<br />
<br />
'''How to Test for SQL Injection Vulnerabilities'''<br />
<br />
* [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities<br />
<br />
'''Other Articles in the OWASP Prevention Cheat Sheet Series'''<br />
<br />
The Prevention Cheat Sheet series was initiated with the following article on XSS Defenses:<br />
<br />
* [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet]]<br />
<br />
[[Category:OWASP Application Security Verification Standard Project]]<br />
[[Category: OWASP Enterprise Security API]]<br />
[[Category:How To]]</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Project_Information:Sqlibench_-_Final_Review_-_First_Reviewer_-_D&diff=45811Project Information:Sqlibench - Final Review - First Reviewer - D2008-11-04T19:48:16Z<p>Fmavituna: </p>
<hr />
<div>[[Category:OWASP_Sqlibench_Project|Clik here to return to the previous page]].<br />
<br />
{| style="width:100%" border="0" align="center"<br />
! colspan="3" align="center" style="background:#4058A0; color:white"|<font color="white">'''50% REVIEW PROCESS''' <br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
Project Deliveries & Objectives <br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|Sqlibench Project's Deliveries & Objectives]]<br />
|-<br />
| style="width:25x%; background:#4058A0" align="center"|<font color="white">'''QUESTIONS''' <br />
| colspan="2" style="width:75%; background:#4058A0" align="left"|<font color="white">'''ANSWERS''' <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
The project reached its objectives. There were some optional features such as videos, integrating OWASP site generator etc. However I don't think these actually effects the overall outcome and the main objectives of the project. Also there were some nice additions to the project such as online version of the results in an interactively browsable way, really detailed documentation (with screenshots and everything), results in one nice PDF matrix, XML output, quite tidy Google Code Project Page etc.<br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please quantify in terms of percentage.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
The project deliveries and objectives completed 100%. <br />
|- <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"|<br />
3. Please do use the right hand side column to provide advice and make work suggestions.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
I think keeping vulnerable applications source code in the SVN repository can make life easier for everyone, although it's not that important since there is a nice package to download.<br />
|- <br />
| style="width:25%; background:white" align="center"|'''PART II''' <br />
| colspan="2" style="width:75%; background:white" align="left"|<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
'''Assessment Criteria'''<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]<br />
|-<br />
| style="width:25%; background:#4058A0" align="center"|<font color="white">'''QUESTIONS''' <br />
| colspan="2" style="width:75%; background:#4058A0" align="left"|<font color="white">'''ANSWERS''' <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
None<br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
Since this project is different than 'a tool', it requires slightly different approach to asses. Such as where to put an 'about box' or 'help'. In interactive criteria interface?, into the documents? or into the vulnerable application itself? Like there is no single installer but there is really well documented process to follow. Overall I believe that the application is got more than Beta Quality.<br />
<br />
<br />
<br />
<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
Beta Quality comments apply to here as well. As far as I know there are some presentations regarding the whole project within the OWASP Turkey Chapter although I couldn't find them in Google Code downloads. As soon as the project page updated with all related documents and user friendly introduction to the project (a summary and easy access to up to date results/matrix) it'll reach the OWASP's Release Quality.<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"|<br />
4. Please do use the right hand side column to provide advice and make work suggestions. <br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
I assume this will be done after the reviews get finished, but for the records "Update the project page."<br />
|}</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Project_Information:Sqlibench_-_Final_Review_-_First_Reviewer_-_D&diff=45809Project Information:Sqlibench - Final Review - First Reviewer - D2008-11-04T19:46:07Z<p>Fmavituna: </p>
<hr />
<div>[[Category:OWASP_Sqlibench_Project|Clik here to return to the previous page]].<br />
<br />
{| style="width:100%" border="0" align="center"<br />
! colspan="3" align="center" style="background:#4058A0; color:white"|<font color="white">'''50% REVIEW PROCESS''' <br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
Project Deliveries & Objectives <br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|Sqlibench Project's Deliveries & Objectives]]<br />
|-<br />
| style="width:25x%; background:#4058A0" align="center"|<font color="white">'''QUESTIONS''' <br />
| colspan="2" style="width:75%; background:#4058A0" align="left"|<font color="white">'''ANSWERS''' <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
The project reached its objectives. There were some optional features such as videos, integrating OWASP site generator etc. However I don't think these actually effects the overall outcome and the main objectives of the project. Also there were some nice additions to the project such as online version of the results in an interactively browsable way, really detailed documentation (with screenshots and everything), results in one nice PDF matrix, XML output, quite tidy Google Code Project Page etc.<br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please quantify in terms of percentage.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
The project deliveries and objectives completed 100%. <br />
|- <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"|<br />
3. Please do use the right hand side column to provide advice and make work suggestions.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
I think keeping vulnerable applications source code in the SVN repository can make life easier for everyone, although it's not that important since there is a nice package to download.<br />
|- <br />
| style="width:25%; background:white" align="center"|'''PART II''' <br />
| colspan="2" style="width:75%; background:white" align="left"|<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
'''Assessment Criteria'''<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]<br />
|-<br />
| style="width:25%; background:#4058A0" align="center"|<font color="white">'''QUESTIONS''' <br />
| colspan="2" style="width:75%; background:#4058A0" align="left"|<font color="white">'''ANSWERS''' <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
None<br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
Since this project is different than 'a tool', it requires slightly different approach to asses. Such as where to put an 'about box' or 'help'. In interactive criteria interface?, into the documents? or into the vulnerable application itself? Like there is no single installer but there is really well documented process to follow. Overall I beilive that the application is got more than Beta Quality.<br />
<br />
<br />
<br />
<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
Beta Quality comments apply to here as well. AFAIK there are some presentations regarding the whole project within the OWASP Turkey Chapter although I couldn't find them in Google Code downloads. As soon as the project page updated with all related documents and user friendly introduction to the project (a summary and easy access to up to date results/matrixes) it'll reach the OWASP's Release Quality.<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"|<br />
4. Please do use the right hand side column to provide advice and make work suggestions. <br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
I assume this will be done after the reviews get finished, but for the records "Update the project page."<br />
|}</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Project_Information:Sqlibench_-_Final_Review_-_First_Reviewer_-_D&diff=45807Project Information:Sqlibench - Final Review - First Reviewer - D2008-11-04T19:43:11Z<p>Fmavituna: </p>
<hr />
<div>[[Category:OWASP_Sqlibench_Project|Clik here to return to the previous page]].<br />
<br />
{| style="width:100%" border="0" align="center"<br />
! colspan="3" align="center" style="background:#4058A0; color:white"|<font color="white">'''50% REVIEW PROCESS''' <br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
Project Deliveries & Objectives <br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|Sqlibench Project's Deliveries & Objectives]]<br />
|-<br />
| style="width:25x%; background:#4058A0" align="center"|<font color="white">'''QUESTIONS''' <br />
| colspan="2" style="width:75%; background:#4058A0" align="left"|<font color="white">'''ANSWERS''' <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
The project reached its objectives. There were some optional possibilities such as videos, integrating OWASP site generator etc. However I don't think these actually effects the overall outcome and the main objectives of the project. Also there were some extra nice additions to the project such as online version of the results in an interactively browsable way, really detailed documentation (with screenshots and everything), results in one nice PDF matrix, XML output etc.<br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please quantify in terms of percentage.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
The project deliveries and objectives completed 100%. <br />
|- <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"|<br />
3. Please do use the right hand side column to provide advice and make work suggestions.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
I think keeping vulnerable applications source code in the SVN repository can make life easier for everyone, although it's not that important since there is a nice package to download.<br />
|- <br />
| style="width:25%; background:white" align="center"|'''PART II''' <br />
| colspan="2" style="width:75%; background:white" align="left"|<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
'''Assessment Criteria'''<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]<br />
|-<br />
| style="width:25%; background:#4058A0" align="center"|<font color="white">'''QUESTIONS''' <br />
| colspan="2" style="width:75%; background:#4058A0" align="left"|<font color="white">'''ANSWERS''' <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
None<br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
Since this project is different than 'a tool', it requires slightly different approach. Such as where to put an 'about box' or 'help'. In interactive criteria interface?, into the documents? or into the vulnerable application itself? Like there is no single installer but there is really well documented process to follow. Overall I beilive that the application is got more than Beta Quality.<br />
<br />
<br />
<br />
<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
Beta Quality comments apply to here as well. AFAIK there are some presentations regarding the whole project within the OWASP Turkey Chapter although I couldn't find them in Google Code downloads. As soon as the project page updated with all related documents and user friendly introduction to the project (a summary and easy access to up to date results/matrixes) it'll reach the OWASP's Release Quality.<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"|<br />
4. Please do use the right hand side column to provide advice and make work suggestions. <br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
I assume this will be done after the reviews get finished, but for the records "Update the project page."<br />
|}</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Project_Information:Sqlibench_-_Final_Review_-_First_Reviewer_-_D&diff=45806Project Information:Sqlibench - Final Review - First Reviewer - D2008-11-04T19:42:02Z<p>Fmavituna: </p>
<hr />
<div>[[Category:OWASP_Sqlibench_Project|Clik here to return to the previous page]].<br />
<br />
{| style="width:100%" border="0" align="center"<br />
! colspan="3" align="center" style="background:#4058A0; color:white"|<font color="white">'''50% REVIEW PROCESS''' <br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
Project Deliveries & Objectives <br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|Sqlibench Project's Deliveries & Objectives]]<br />
|-<br />
| style="width:25x%; background:#4058A0" align="center"|<font color="white">'''QUESTIONS''' <br />
| colspan="2" style="width:75%; background:#4058A0" align="left"|<font color="white">'''ANSWERS''' <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
The project reached its objectives. There were some optional possibilities such as videos, integrating OWASP site generator etc. However I don't think these actually effects the overall outcome and the main objectives of the project. Also there were some extra nice additions to the project such as online version of the results in an interactively browsable way, really detailed documentation (with screenshots and everything), results in one nice PDF matrix, XML output etc.<br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please quantify in terms of percentage.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
The project deliveries and objectives complete 100%. <br />
|- <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"|<br />
3. Please do use the right hand side column to provide advice and make work suggestions.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
I think keeping vulnerable applications source code in the SVN repository can make life easier for everyone, although it's not that important since there is a nice package to download.<br />
|- <br />
| style="width:25%; background:white" align="center"|'''PART II''' <br />
| colspan="2" style="width:75%; background:white" align="left"|<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
'''Assessment Criteria'''<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]<br />
|-<br />
| style="width:25%; background:#4058A0" align="center"|<font color="white">'''QUESTIONS''' <br />
| colspan="2" style="width:75%; background:#4058A0" align="left"|<font color="white">'''ANSWERS''' <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
None<br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
Since this project is different than 'a tool', it requires slightly different approach. Such as where to put an 'about box' or 'help'. In interactive criteria interface?, into the documents? or into the vulnerable application itself? Like there is no single installer but there is really well documented process to follow. Overall I beilive that the application is got more than Beta Quality.<br />
<br />
<br />
<br />
<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
Beta Quality comments apply to here as well. AFAIK there are some presentations regarding the whole project within the OWASP Turkey Chapter although I couldn't find them in Google Code downloads. As soon as the project page updated with all related documents and user friendly introduction to the project (a summary and easy access to up to date results/matrixes) it'll reach the OWASP's Release Quality.<br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"|<br />
4. Please do use the right hand side column to provide advice and make work suggestions. <br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
I assume this will be done after the reviews get finished, but for the records "Update the project page."<br />
|}</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Category:OWASP_NetBouncer_RoadMap&diff=36188Category:OWASP NetBouncer RoadMap2008-08-15T12:50:53Z<p>Fmavituna: </p>
<hr />
<div>* Developing a sample web application using NetBouncer<br />
* Improving the current API and making it easier to use<br />
* Detailed documentation about the API with samples<br />
* Adding new rules</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_Captcha_(OWASP-AT-008)&diff=34989Testing for Captcha (OWASP-AT-008)2008-07-30T08:35:27Z<p>Fmavituna: /* References */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
== Brief Summary ==<br />
CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the generated CAPTCHA is unbreakable.<br />
This section will help you to identify these kinds of attacks.<br />
<br />
== Description of the Issue == <br />
<br />
<br />
Although CAPTCHA is not an authentication control, its use can be very efficient against:<br />
<br />
* [https://www.owasp.org/index.php/Testing_for_user_enumeration enumeration attacks] (login, registration or password reset forms are often vulnerable to enumeration attacks - without CAPTCHA the attacker can gain valid usernames, phone numbers or any other sensitive information in a short time)<br />
* automated sending of many GET/POST requests in a short time where it is undesirable (e.g. SMS/MMS/email flooding), CAPTCHA provides a rate limiting function<br />
* automated creation/using of the account that should be used only by humans (e.g. creating webmail accounts, stop spamming)<br />
* automated posting to blogs, forums and wikis, whether as a result of commercial promotion, or harassment and vandalism<br />
* any automated attacks that massively gain or misuse sensitive information from the application<br />
<br />
Using CAPTCHAs as a CSRF protection is not recommended (because there are [http://www.owasp.org/index.php/Testing_for_CSRF stronger CSRF countermeasures]).<br />
<br />
<br><br />
These vulnerabilities are quite common in many CAPTCHA implementations:<br />
<br />
* generated image CAPTCHA is weak, this can be identified (without any complex computer recognition systems) only by a simple comparison with already broken CAPTCHAs <br />
* generated CAPTCHA questions have a very limited set of possible answers <br />
<br />
* the value of decoded CAPTCHA is sent by client (as a GET parameter or as a hidden field of POST form). This value is often: <br />
** encrypted by simple algorithm and can be easily decrypted by observing of multiple decoded CAPTCHA values<br />
** hashed by weak hash function (e.g. MD5) and can be broken using a rainbow table<br />
<br />
* possibility of replay attacks: <br />
** the application does not keep track what ID of CAPTCHA image is sent to the user. Therefore the attacker can simple gain the appropriate CAPTCHA image and it's ID, solve it and send old value of decoded CAPTCHA with its corresponding ID (ID of CAPTCHA can be hash of decoded CAPTCHA or any unique identifier) <br />
** the application does not destroy the session when the correct phrase is entered - by reusing the session ID of a known CAPTCHA it is possible to bypass CAPTCHA protected page<br />
<br />
<br />
<br><br />
<br />
== Black Box testing and example ==<br />
<br />
Use intercepting fault injection proxy (e.g. [http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project WebScarab]) to:<br />
<br />
* identify all parameters that are sent in addition to the decoded CAPTCHA value from the client to the server (these parameters can contain encrypted or hashed values of decoded CAPTCHA and CAPTCHA ID number)<br />
* try to send old decoded CAPTCHA value with old CAPTCHA ID (if the application accepts it, it is vulnerable to replay attacks)<br />
* try to send old decoded CAPTCHA value with old session ID (if the application accepts it, it is vulnerable to replay attacks)<br />
<br />
Find out if similar CAPTCHAs are already broken, broken CAPTCHA images can be found here [http://www.cs.sfu.ca/~mori/research/gimpy/ez/ gimpy], [http://libcaca.zoy.org/wiki/PWNtcha PWNtcha], [http://www.lafdc.com/captcha/ lafdc].<br />
<br />
Verify if a set of possible answers for CAPTCHA is limited and can be easily determined.<br />
<br />
== Gray Box testing and example == <br />
<br />
Audit the application source code in order to reveal: <br />
<br />
* used CAPTCHA implementation and version - there are many known vulnerabilities in widely used CAPTCHA implementations, see http://osvdb.org/search?request=captcha<br />
* if the application sends encrypted or hashed value from the client (which is a very bad security practice) verify if used encryption or hash algorithm is sufficiently strong<br />
<br />
<br />
== References ==<br />
<br />
'''Captcha Decoders'''<br><br />
* [http://libcaca.zoy.org/wiki/PWNtcha (Opensource) PWNtcha captcha decoder]<br />
* [http://churchturing.org/captcha-dist/ (Opensource) The Captcha Breaker]<br />
* [http://www.lafdc.com/captcha/ (Commercial) Captcha decoder]<br />
* [http://www.captchakiller.com/ (Commercial - Free) Online Captcha Decoder] Free limited usage, enough for testing.<br />
<br />
'''Articles'''<br><br />
* [http://www.cs.sfu.ca/~mori/research/gimpy/ Breaking a Visual CAPTCHA]<br />
* [http://www.puremango.co.uk/cm_breaking_captcha_115.php Breaking CAPTCHAs Without Using OCR]<br />
* [http://securesoftware.blogspot.com/2007/11/captcha-placebo-security-control-for.html Why CAPTCHA is not a security control for user authentication]</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_Captcha_(OWASP-AT-008)&diff=34988Testing for Captcha (OWASP-AT-008)2008-07-30T08:35:06Z<p>Fmavituna: /* References */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
== Brief Summary ==<br />
CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the generated CAPTCHA is unbreakable.<br />
This section will help you to identify these kinds of attacks.<br />
<br />
== Description of the Issue == <br />
<br />
<br />
Although CAPTCHA is not an authentication control, its use can be very efficient against:<br />
<br />
* [https://www.owasp.org/index.php/Testing_for_user_enumeration enumeration attacks] (login, registration or password reset forms are often vulnerable to enumeration attacks - without CAPTCHA the attacker can gain valid usernames, phone numbers or any other sensitive information in a short time)<br />
* automated sending of many GET/POST requests in a short time where it is undesirable (e.g. SMS/MMS/email flooding), CAPTCHA provides a rate limiting function<br />
* automated creation/using of the account that should be used only by humans (e.g. creating webmail accounts, stop spamming)<br />
* automated posting to blogs, forums and wikis, whether as a result of commercial promotion, or harassment and vandalism<br />
* any automated attacks that massively gain or misuse sensitive information from the application<br />
<br />
Using CAPTCHAs as a CSRF protection is not recommended (because there are [http://www.owasp.org/index.php/Testing_for_CSRF stronger CSRF countermeasures]).<br />
<br />
<br><br />
These vulnerabilities are quite common in many CAPTCHA implementations:<br />
<br />
* generated image CAPTCHA is weak, this can be identified (without any complex computer recognition systems) only by a simple comparison with already broken CAPTCHAs <br />
* generated CAPTCHA questions have a very limited set of possible answers <br />
<br />
* the value of decoded CAPTCHA is sent by client (as a GET parameter or as a hidden field of POST form). This value is often: <br />
** encrypted by simple algorithm and can be easily decrypted by observing of multiple decoded CAPTCHA values<br />
** hashed by weak hash function (e.g. MD5) and can be broken using a rainbow table<br />
<br />
* possibility of replay attacks: <br />
** the application does not keep track what ID of CAPTCHA image is sent to the user. Therefore the attacker can simple gain the appropriate CAPTCHA image and it's ID, solve it and send old value of decoded CAPTCHA with its corresponding ID (ID of CAPTCHA can be hash of decoded CAPTCHA or any unique identifier) <br />
** the application does not destroy the session when the correct phrase is entered - by reusing the session ID of a known CAPTCHA it is possible to bypass CAPTCHA protected page<br />
<br />
<br />
<br><br />
<br />
== Black Box testing and example ==<br />
<br />
Use intercepting fault injection proxy (e.g. [http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project WebScarab]) to:<br />
<br />
* identify all parameters that are sent in addition to the decoded CAPTCHA value from the client to the server (these parameters can contain encrypted or hashed values of decoded CAPTCHA and CAPTCHA ID number)<br />
* try to send old decoded CAPTCHA value with old CAPTCHA ID (if the application accepts it, it is vulnerable to replay attacks)<br />
* try to send old decoded CAPTCHA value with old session ID (if the application accepts it, it is vulnerable to replay attacks)<br />
<br />
Find out if similar CAPTCHAs are already broken, broken CAPTCHA images can be found here [http://www.cs.sfu.ca/~mori/research/gimpy/ez/ gimpy], [http://libcaca.zoy.org/wiki/PWNtcha PWNtcha], [http://www.lafdc.com/captcha/ lafdc].<br />
<br />
Verify if a set of possible answers for CAPTCHA is limited and can be easily determined.<br />
<br />
== Gray Box testing and example == <br />
<br />
Audit the application source code in order to reveal: <br />
<br />
* used CAPTCHA implementation and version - there are many known vulnerabilities in widely used CAPTCHA implementations, see http://osvdb.org/search?request=captcha<br />
* if the application sends encrypted or hashed value from the client (which is a very bad security practice) verify if used encryption or hash algorithm is sufficiently strong<br />
<br />
<br />
== References ==<br />
<br />
'''Captcha Decoders'''<br><br />
* [http://libcaca.zoy.org/wiki/PWNtcha (Opensource) PWNtcha captcha decoder]<br />
* [http://churchturing.org/captcha-dist/ (Opensource) The Captcha Breaker]<br />
* [http://www.lafdc.com/captcha/ (Commercial) Captcha decoder]<br />
* [http://www.captchakiller.com/ Online Captcha Decoder] Free limited usage, enough for testing.<br />
<br />
'''Articles'''<br><br />
* [http://www.cs.sfu.ca/~mori/research/gimpy/ Breaking a Visual CAPTCHA]<br />
* [http://www.puremango.co.uk/cm_breaking_captcha_115.php Breaking CAPTCHAs Without Using OCR]<br />
* [http://securesoftware.blogspot.com/2007/11/captcha-placebo-security-control-for.html Why CAPTCHA is not a security control for user authentication]</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Project_Information:Sqlibench&diff=34057Project Information:Sqlibench2008-07-14T12:45:10Z<p>Fmavituna: </p>
<hr />
<div>{| style="width:100%" border="0" align="center"<br />
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''PROJECT IDENTIFICATION''' <br />
|-<br />
| style="width:15%; background:#7B8ABD" align="center"|'''Project Name'''<br />
| colspan="6" style="width:85%; background:#cccccc" align="left"|<font color="black">'''SQLiBENCH''' <br />
|-<br />
| style="width:15%; background:#7B8ABD" align="center"| '''Short Project Description''' <br />
| colspan="6" style="width:85%; background:#cccccc" align="left"|SQLiBENCH is a benchmarking project of automatic sql injectors related to dumping databases. There're a lot of and great open source tools (takeover/dumpers/hybrid) for taking advantage of an sql injection vulnerability both used by web application security specialists and attackers. Techniques used, databases supported, algorithms employed and abilities implemented by these "sql injectors" greatly varies. It should be important to standardize general vulnerability techniques exists in web applications and one of the biggest one is sql manipulation. In our effort, we aim to produce a standardization of techniques used in exploiting sql injection by automatic tools.<br />
|-<br />
| style="width:15%; background:#7B8ABD" align="center"|'''Email Contacts'''<br />
| style="width:14%; background:#cccccc" align="center"|Project Leaders<br>[mailto:urgunb(at)hotmail.com '''Bedirhan Urgun''']<br />
| style="width:14%; background:#cccccc" align="center"|Project Contributors<br>[mailto:mesut(at)h-labs.org '''Mesut Timur''']<br />
| style="width:14%; background:#cccccc" align="center"|[https://lists.owasp.org/mailman/listinfo/owasp-sqlibench-project '''Mailing List/Subscribe''']<br>[mailto:owasp-sqlibench-project(at)lists.owasp.org '''Mailing List/Use''']<br />
| style="width:14%; background:#cccccc" align="center"|First Reviewer<br>[mailto:ferruh(at)mavituna.com '''Ferruh Mavituna''']<br/> [[Project Information:Sqlibench:Ferruh|background info]]<br />
| style="width:14%; background:#cccccc" align="center"|Second Reviewer<br>[mailto:KFuller(at)DMV.CA.gov '''Kevin Fuller'''] <br/> [[Project Information:Sqlibench:Kevin|background info]] <br />
| style="width:15%; background:#cccccc" align="center"|OWASP Board Member<br>(not applicable)<br />
|}<br />
{| style="width:100%" border="0" align="center"<br />
! colspan="6" align="center" style="background:#4058A0; color:white"|<font color="white">'''PROJECT MAIN LINKS''' <br />
|-<br />
| style="width:100%; background:#cccccc" align="center"|<br />
* SQLiBENCH is a benchmarking project and the documentation can be found at [http://code.google.com/p/sqlibench/ SQLiBENCH.]<br />
* Here you can find the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008_Applications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29 SQLiBENCH Project Proposal] document<br />
* Here you can find the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008_Applications_-_Need_Futher_Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29 Further Clarifications] document<br />
<br />
|}<br />
{| style="width:100%" border="0" align="center"<br />
! colspan="6" align="center" style="background:#4058A0; color:white"|<font color="white">'''SPONSORS & GUIDELINES''' <br />
|-<br />
| style="width:50%; background:#cccccc" align="center"|[[OWASP Summer of Code 2008|Sponsor - '''OWASP Summer of Code 2008''']] <br />
| style="width:50%; background:#cccccc" align="center"|[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''Sponsored Project/Guidelines/Roadmap''']]<br />
|}<br />
{| style="width:100%" border="0" align="center"<br />
! colspan="5" align="center" style="background:#4058A0; color:white"|ASSESSMENT AND REVIEW PROCESS<br />
|-<br />
| style="width:15%; background:#6C82B5" align="center"|'''Review/Reviewer''' <br />
| style="width:21%; background:#b3b3b3" align="center"|'''Author's Self Evaluation'''<br>(applicable for Alpha Quality & further) <br />
| style="width:21%; background:#b3b3b3" align="center"|'''First Reviewer'''<br>(applicable for Alpha Quality & further)<br />
| style="width:21%; background:#b3b3b3" align="center"|'''Second Reviewer'''<br>(applicable for Beta Quality & further)<br />
| style="width:22%; background:#b3b3b3" align="center"|'''OWASP Board Member'''<br>(applicable just for Release Quality) <br />
|-<br />
| style="width:15%; background:#7B8ABD" align="center"|'''50% Review''' <br />
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached?<br>'''Yes'''<br>---------<br>[[Project Information:Sqlibench - 50 Review - Self Evaluation - A|See&Edit: 50% Review/Self-Evaluation (A)]]<br />
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached?<br>'''Yes'''<br>---------<br>[[Project Information:Sqlibench - 50 Review - First Reviewer - C|See&Edit: 50% Review/1st Reviewer (C)]]<br />
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached?<br>'''Yes/No''' (To update)<br>---------<br>[[Project Information:Sqlibench 50 Review Second Review E|See&Edit: 50%Review/2nd Reviewer (E)]]<br />
| style="width:22%; background:#C2C2C2" align="center"|X <br />
|-<br />
| style="width:15%; background:#7B8ABD" align="center"|'''Final Review''' <br />
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached?<br>'''Yes/No''' (To update)<br>---------<br>What status has been reached?<br>'''Season of Code''' - (To update)<br>---------<br>[[Project Information:Sqlibench - Final Review - Self Evaluation - B|See&Edit: Final Review/SelfEvaluation (B)]]<br />
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached?<br>'''Yes/No''' (To update)<br>---------<br>What status has been reached?<br>'''Season of Code''' - (To update)<br>---------<br>[[Project Information:Sqlibench - Final Review - First Reviewer - D|See&Edit: Final Review/1st Reviewer (D)]]<br />
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached?<br>'''Yes/No''' (To update)<br>---------<br>What status has been reached?<br>'''Season of Code''' - (To update)<br>---------<br>[[Project Information:Sqlibench - Final Review - Second Reviewer - F|See&Edit: Final Review/2nd Reviewer (F)]]<br />
| style="width:22%; background:#C2C2C2" align="center"|X<br />
|-<br />
|}</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Project_Information:Sqlibench_-_50_Review_-_First_Reviewer_-_C&diff=34056Project Information:Sqlibench - 50 Review - First Reviewer - C2008-07-14T12:40:49Z<p>Fmavituna: </p>
<hr />
<div>[[Category:OWASP_Sqlibench_Project|Clik here to return to the previous page]].<br />
<br />
{| style="width:100%" border="0" align="center"<br />
! colspan="3" align="center" style="background:#4058A0; color:white"|<font color="white">'''50% REVIEW PROCESS''' <br />
|- <br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
Project Deliveries & Objectives <br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|Sqlibench Project's Deliveries & Objectives]]<br />
|-<br />
| style="width:25x%; background:#4058A0" align="center"|<font color="white">'''QUESTIONS''' <br />
| colspan="2" style="width:75%; background:#4058A0" align="left"|<font color="white">'''ANSWERS''' <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"| <br />
<br />
50% of the project's been finished as expected. I couldn't go through all steps in the documentation yet to see if it works as expected. Although documentation to build up the benchmarking is well written and detailed enough. <br />
<br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"| <br />
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#SQL_Injector_Benchmarking_Project_.28SQLiBENCH.29|'''the assumed ones''']], please quantify in terms of percentage.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
<br />
50% of all over the project and 100% of the first part completed. Apparently creating videos was also in this part of the project which I don't see it's really necessary since the documentation is fairly easy to follow. <br />
|- <br />
|-<br />
| style="width:25%; background:#7B8ABD" align="center"|<br />
3. Please do use the right hand side column to provide advice and make work suggestions.<br />
| colspan="2" style="width:75%; background:#cccccc" align="left"|<br />
<br />
I really like the professional presentation of the project and detailed documentation. <br />
<br />
My humble recommendations are:<br />
<br />
* I couldn't locate any of the source code in Google code SVN, it'd be nice to put all source such as presentation PHP into there (as well as any other sql files or script).<br />
* Presentation format looks quite nice. It'd be nice to have another static big matrix to see overview of the results.<br />
* Is there any plan to prepare a documentation to benchmark new tools? So other people can contribute as well as SQLI tool developers might find it quite useful.<br />
<br />
|}</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=32515Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-06-27T09:32:00Z<p>Fmavituna: /* Gray Box testing and example */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supports some extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br />
<br />
<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki><br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br />
<br />
<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br />
<br />
== Black Box testing and example ==<br />
'''Testing for SQL Wildcard Attacks:''' <br><br />
Craft a query which will not return a result and includes several wildcards. You can use one of the example inputs below.<br><br />
Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable. <br />
<br />
=== Example Attack Inputs to send ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
* <nowiki>%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%</nowiki><br><br />
<br />
...<br><br />
'''Result Expected:'''<br><br />
IF the application is vulnerable, response time should be longer than the usual.<br />
<br><br><br />
<br />
=== How to craft search keywords for testing ===<br />
<br />
* Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;<br />
* During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough; <br />
* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually longer execution time, this can be used to improve the affect, some examples: <br />
** <nowiki>LIKE '%_[a[! -z]@$!_% - 1050 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.</nowiki> <br />
* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application; <br />
* Starting with % and ending with % generally will cause more expensive queries;<br />
* Some implementations might cache search results. During the testing every search query should be slightly different to avoid this; <br />
* Performance is always about experimenting. Try different combinations to find the most expensive queries for that particular target system and data.<br />
<br />
== Gray Box testing and example == <br />
'''Testing for SQL Wildcard Attacks:'''<br />
<br />
Query execution times can be observed in the database server, if certain queries takes longer time it can be an indication of SQL wildcard attacks.<br />
<br />
To test against application layer DoS attacks, it's important to watch HTTP logs and analyse response times. If response times of certain pages in certain queries is longer than usual, those pages can be susceptible to SQL wildcard attacks.<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=32514Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-06-27T09:28:04Z<p>Fmavituna: /* Gray Box testing and example */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supports some extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br />
<br />
<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki><br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br />
<br />
<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br />
<br />
== Black Box testing and example ==<br />
'''Testing for SQL Wildcard Attacks:''' <br><br />
Craft a query which will not return a result and includes several wildcards. You can use one of the example inputs below.<br><br />
Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable. <br />
<br />
=== Example Attack Inputs to send ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
* <nowiki>%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%</nowiki><br><br />
<br />
...<br><br />
'''Result Expected:'''<br><br />
IF the application is vulnerable, response time should be longer than the usual.<br />
<br><br><br />
<br />
=== How to craft search keywords for testing ===<br />
<br />
* Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;<br />
* During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough; <br />
* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually longer execution time, this can be used to improve the affect, some examples: <br />
** <nowiki>LIKE '%_[a[! -z]@$!_% - 1050 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.</nowiki> <br />
* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application; <br />
* Starting with % and ending with % generally will cause more expensive queries;<br />
* Some implementations might cache search results. During the testing every search query should be slightly different to avoid this; <br />
* Performance is always about experimenting. Try different combinations to find the most expensive queries for that particular target system and data.<br />
<br />
== Gray Box testing and example == <br />
'''Testing for SQL Wildcard Attacks:'''<br />
<br />
Query execution times can be observed in the database server, if certain queries takes longer time it can be an indication of SQL Wildcard attacks.<br />
<br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=32513Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-06-27T09:08:47Z<p>Fmavituna: /* Description of the Issue */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supports some extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br />
<br />
<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki><br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br />
<br />
<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br />
<br />
== Black Box testing and example ==<br />
'''Testing for SQL Wildcard Attacks:''' <br><br />
Craft a query which will not return a result and includes several wildcards. You can use one of the example inputs below.<br><br />
Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable. <br />
<br />
=== Example Attack Inputs to send ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
* <nowiki>%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%</nowiki><br><br />
<br />
...<br><br />
'''Result Expected:'''<br><br />
IF the application is vulnerable, response time should be longer than the usual.<br />
<br><br><br />
<br />
=== How to craft search keywords for testing ===<br />
<br />
* Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;<br />
* During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough; <br />
* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually longer execution time, this can be used to improve the affect, some examples: <br />
** <nowiki>LIKE '%_[a[! -z]@$!_% - 1050 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.</nowiki> <br />
* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application; <br />
* Starting with % and ending with % generally will cause more expensive queries;<br />
* Some implementations might cache search results. During the testing every search query should be slightly different to avoid this; <br />
* Performance is always about experimenting. Try different combinations to find the most expensive queries for that particular target system and data.<br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=32512Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-06-27T09:08:21Z<p>Fmavituna: /* Description of the Issue */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supports some extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br />
<br />
'''<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki>'''<br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
'''<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki>'''<br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br />
<br />
'''<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br>'''<br />
<br />
== Black Box testing and example ==<br />
'''Testing for SQL Wildcard Attacks:''' <br><br />
Craft a query which will not return a result and includes several wildcards. You can use one of the example inputs below.<br><br />
Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable. <br />
<br />
=== Example Attack Inputs to send ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
* <nowiki>%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%</nowiki><br><br />
<br />
...<br><br />
'''Result Expected:'''<br><br />
IF the application is vulnerable, response time should be longer than the usual.<br />
<br><br><br />
<br />
=== How to craft search keywords for testing ===<br />
<br />
* Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;<br />
* During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough; <br />
* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually longer execution time, this can be used to improve the affect, some examples: <br />
** <nowiki>LIKE '%_[a[! -z]@$!_% - 1050 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.</nowiki> <br />
* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application; <br />
* Starting with % and ending with % generally will cause more expensive queries;<br />
* Some implementations might cache search results. During the testing every search query should be slightly different to avoid this; <br />
* Performance is always about experimenting. Try different combinations to find the most expensive queries for that particular target system and data.<br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=32511Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-06-27T09:04:20Z<p>Fmavituna: /* Example Attack Inputs to send */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supportssome extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br><br />
'''<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki>'''<br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
'''<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br>'''<br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br><br />
'''<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br>'''<br />
<br />
<br><br />
<br />
== Black Box testing and example ==<br />
'''Testing for SQL Wildcard Attacks:''' <br><br />
Craft a query which will not return a result and includes several wildcards. You can use one of the example inputs below.<br><br />
Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable. <br />
<br />
=== Example Attack Inputs to send ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
* <nowiki>%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%</nowiki><br><br />
<br />
...<br><br />
'''Result Expected:'''<br><br />
IF the application is vulnerable, response time should be longer than the usual.<br />
<br><br><br />
<br />
=== How to craft search keywords for testing ===<br />
<br />
* Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;<br />
* During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough; <br />
* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually longer execution time, this can be used to improve the affect, some examples: <br />
** <nowiki>LIKE '%_[a[! -z]@$!_% - 1050 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.</nowiki> <br />
* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application; <br />
* Starting with % and ending with % generally will cause more expensive queries;<br />
* Some implementations might cache search results. During the testing every search query should be slightly different to avoid this; <br />
* Performance is always about experimenting. Try different combinations to find the most expensive queries for that particular target system and data.<br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=32510Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-06-27T09:00:06Z<p>Fmavituna: /* Black Box testing and example */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supportssome extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br><br />
'''<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki>'''<br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
'''<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br>'''<br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br><br />
'''<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br>'''<br />
<br />
<br><br />
<br />
== Black Box testing and example ==<br />
'''Testing for SQL Wildcard Attacks:''' <br><br />
Craft a query which will not return a result and includes several wildcards. You can use one of the example inputs below.<br><br />
Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable. <br />
<br />
=== Example Attack Inputs to send ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
* <nowiki>%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%</nowiki><br><br />
<br />
...<br><br />
'''Result Expected:'''<br><br />
The application's response time should take longer than the usual.<br />
<br><br><br />
<br />
=== How to craft search keywords for testing ===<br />
<br />
* Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;<br />
* During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough; <br />
* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually longer execution time, this can be used to improve the affect, some examples: <br />
** <nowiki>LIKE '%_[a[! -z]@$!_% - 1050 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.</nowiki> <br />
* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application; <br />
* Starting with % and ending with % generally will cause more expensive queries;<br />
* Some implementations might cache search results. During the testing every search query should be slightly different to avoid this; <br />
* Performance is always about experimenting. Try different combinations to find the most expensive queries for that particular target system and data.<br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=32509Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-06-27T08:59:32Z<p>Fmavituna: /* Example Attack Inputs to send */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supportssome extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br><br />
'''<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki>'''<br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
'''<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br>'''<br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br><br />
'''<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br>'''<br />
<br />
<br><br />
<br />
== Black Box testing and example ==<br />
'''Testing for SQL Wildcard Attacks:''' <br><br />
Craft a query which will not return a result and includes several wildcards. Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable. <br />
<br />
=== Example Attack Inputs to send ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
* <nowiki>%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%</nowiki><br><br />
<br />
...<br><br />
'''Result Expected:'''<br><br />
The application's response time should take longer than the usual.<br />
<br><br><br />
<br />
=== How to craft search keywords for testing ===<br />
<br />
* Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;<br />
* During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough; <br />
* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually longer execution time, this can be used to improve the affect, some examples: <br />
** <nowiki>LIKE '%_[a[! -z]@$!_% - 1050 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.</nowiki> <br />
* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application; <br />
* Starting with % and ending with % generally will cause more expensive queries;<br />
* Some implementations might cache search results. During the testing every search query should be slightly different to avoid this; <br />
* Performance is always about experimenting. Try different combinations to find the most expensive queries for that particular target system and data.<br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=32508Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-06-27T08:55:34Z<p>Fmavituna: /* How to craft search keywords for testing */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supportssome extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br><br />
'''<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki>'''<br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
'''<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br>'''<br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br><br />
'''<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br>'''<br />
<br />
<br><br />
<br />
== Black Box testing and example ==<br />
'''Testing for SQL Wildcard Attacks:''' <br><br />
Craft a query which will not return a result and includes several wildcards. Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable. <br />
<br />
=== Example Attack Inputs to send ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
* <nowiki>%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%</nowiki><br><br />
<br />
...<br><br />
'''Result Expected:'''<br><br />
The application's response time should take longer than the usual. <br />
...<br><br><br />
<br />
=== How to craft search keywords for testing ===<br />
<br />
* Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;<br />
* During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough; <br />
* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually longer execution time, this can be used to improve the affect, some examples: <br />
** <nowiki>LIKE '%_[a[! -z]@$!_% - 1050 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.</nowiki> <br />
* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application; <br />
* Starting with % and ending with % generally will cause more expensive queries;<br />
* Some implementations might cache search results. During the testing every search query should be slightly different to avoid this; <br />
* Performance is always about experimenting. Try different combinations to find the most expensive queries for that particular target system and data.<br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=32507Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-06-27T08:55:12Z<p>Fmavituna: /* Black Box testing and example */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supportssome extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br><br />
'''<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki>'''<br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
'''<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br>'''<br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br><br />
'''<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br>'''<br />
<br />
<br><br />
<br />
== Black Box testing and example ==<br />
'''Testing for SQL Wildcard Attacks:''' <br><br />
Craft a query which will not return a result and includes several wildcards. Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable. <br />
<br />
=== Example Attack Inputs to send ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
* <nowiki>%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%</nowiki><br><br />
<br />
...<br><br />
'''Result Expected:'''<br><br />
The application's response time should take longer than the usual. <br />
...<br><br><br />
<br />
=== How to craft search keywords for testing ===<br />
<br />
* Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;<br />
* During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough; <br />
* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually longer execution time, this can be used to improve the affect, some examples: <br />
** <nowiki>LIKE '%_[a[! -z]@$!_% - 1050 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms. </nowiki><br />
** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.</nowiki> <br />
* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application; <br />
* Starting with % and ending with % generally will cause more expensive queries;<br />
* Some implementations might cache search results. During the testing every search query should be slightly different to avoid this; <br />
* Performance is always about experimenting. Try different combinations to find the most expensive queries for that particular target system and data.<br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Talk:Testing_for_CSRF_(OTG-SESS-005)&diff=32428Talk:Testing for CSRF (OTG-SESS-005)2008-06-26T10:41:48Z<p>Fmavituna: New section: Rererrer</p>
<hr />
<div>This chapter really should be called Cross site request forgeries. Session riding is becoming old skool. [[User:Vanderaj|Vanderaj]] 20:25, 15 January 2007 (EST)<br />
<br><br />
Good Call. Jeff has made the changes. [[User:Mmeucci|Matteo Meucci]] 20.00, 18 Janaury 2007<br />
<br />
== Point 3 needs to be clarified ==<br />
<br />
Point 3 states "Point 3) By “known by the browser” we mean information such as cookies or http-based authentication information (such as Basic Authentication; NOT form-based authentication)..."<br />
<br />
Form-based authentication in its generic sense, means that we initially perform authentication via a form. If we do this, our session ID can be stored in a non-persistent cookie (e.g., session cookie), which is still vulnerable to CSRF attacks since they are automatically sent along with every request. I think implying that form-based authentication is secure is inaccurate. The only time form-based authN is safe from CSRF is if session cookies are not used and the session ID is rewritten in the URL (though this is another vulnerability in itself).<br />
<br />
== Rererrer ==<br />
<br />
I removed referrer usage recommendation because we should not recommend referrer checking by any means.<br />
<br />
First reason it's known to be suspected to spoof attacks (already mentioned), Secondly rejecting empty referrers will cause to block legitimate users by mistake therefore developers will accept empty referrers as well which is even easier bypass as an attacker. Therefore as OWASP we should not recommend a bad practice to developers.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_CSRF_(OTG-SESS-005)&diff=32427Testing for CSRF (OTG-SESS-005)2008-06-26T10:38:15Z<p>Fmavituna: /* Description of the Issue */</p>
<hr />
<div>[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
==Brief Summary==<br />
<br />
[[Cross-Site Request Forgery]] (CSRF) is about forcing an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attackers choosing. A successful [[CSRF]] exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.<br />
<br />
==Description of the Issue==<br />
The way CSRF is accomplished relies on the following facts:<br><br />
1) Web browser behavior regarding the handling of session-related information such as cookies and http authentication information;<br><br />
2) Knowledge of valid web application URLs on the side of the attacker;<br><br />
3) Application session management relying only on information which is known by the browser;<br><br />
4) Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag ''img''.<br><br />
<br />
Points 1, 2, and 3 are essential for the vulnerability to be present, while point 4 is accessory and facilitates the actual exploitation, but is not strictly required.<br />
<br />
Point 1) Browsers automatically send information which is used to identify a user session. Suppose ''site'' is a site hosting a web application, and the user ''victim'' has just authenticated himself to ''site''. In response, ''site'' sends ''victim'' a cookie which identifies requests send by ''victim'' as belonging to ''victim’s'' authenticated session. Basically, once the browser receives the cookie set by ''site'', it will automatically send it along with any further requests directed to ''site''.<br />
<br />
Point 2) If the application does not make use of session-related information in URLs, then it means that the application URLs, their parameters and legitimate values may be identified (either by code analysis or by accessing the application and taking note of forms and URLs embedded in the HTML/JavaScript).<br />
<br />
Point 3) By “known by the browser” we mean information such as cookies or http-based authentication information (such as Basic Authentication; NOT form-based authentication), which are stored by the browser and subsequently resent at each request directed towards an application area requesting that authentication. The vulnerabilities discussed next apply to applications which rely entirely on this kind of information to identify a user session.<br />
<br />
Suppose, for simplicity's sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If ''victim'' has already authenticated himself, submitting another request causes the cookie to be automatically sent with it (see picture, where the user accesses an application on www.example.com).<br />
<br />
<center>[[Image:session_riding.GIF]]</center><br />
<br />
<br />
The GET request could be originated in several different ways:<br />
<br />
* by the user, who is using the actual web application;<br />
* by the user, who types the URL it directly in the browser;<br />
* by the user, who follows a link (external to the application) pointing to the URL.<br />
<br />
These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There is a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email message, or appear in a malicious web site where the user is lured, i.e. the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the application. If the user clicks on the link, since it was already authenticated by the web application on ''site'', the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application – probably not what the user expects to happen! Think of a malicious link causing a fund transfer on a web banking application to appreciate the implications...<br />
<br />
By using a tag such as ''img'', as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing him to visit an URL referring to a page containing the following (oversimplified) HTML:<br />
<br />
<pre><br />
<html><body><br />
<br />
...<br />
<br />
<img src=”https://www.company.example/action” width=”0” height=”0”><br />
<br />
...<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well. This results into a request being automatically sent to the web application hosted on ''site''. It is not important that the image URL does not refer to a proper image, its presence will trigger the request specified in the ''src'' field anyway; this happens provided that images download is not disabled in the browsers, which is a typical configuration since disabling images would cripple most web applications beyond usability.<br />
<br />
The problem here is a consequence of the following facts:<br />
<br />
* there are HTML tags whose appearance in a page result in automatic http request execution (''img'' being one of those);<br />
* the browser has no way to tell that the resource referenced by ''img ''is not actually an image and is in fact not legitimate;<br />
* image loading happens regardless of the location of the alleged image, i.e. the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications.<br />
<br />
It is the fact that HTML content unrelated to the web application may refer components in the application, and the fact that the browser automatically composes a legal request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information related to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs impossible.<br />
<br />
The problem might be even worse, since in integrated mail/browser environments simply displaying an email message containing the image would result in the execution of the request to the web application with the associated browser cookie.<br />
<br />
Things may be obfuscated further, by referencing seemingly valid image URLs such as<br />
<br />
<img src=”https://[attacker]/picture.gif” width=”0” height=”0”><br />
<br />
where [attacker] is a site controlled by the attacker, and by utilizing a redirect mechanism on http://[attacker]/picture.gif to http://[thirdparty]/action.<br />
<br />
Cookies are not the only example involved in this kind of vulnerability. Web applications whose session information is entirely supplied by the browser are vulnerable too. This includes applications relying on HTTP authentication mechanisms alone, since the authentication information is known by the browser and is sent automatically upon each request. This DOES NOT include form-based authentication, which occurs just once and generates some form of session-related information (of course, in this case, such information is expressed simply as a cookie and can we fall back to one of the previous cases).<br />
<br />
'''Sample scenario.'''<br />
<br />
Let’s suppose that the victim is logged on to a firewall web management application. To log in, a user has to authenticate himself; subsequently, session information is stored in a cookie.<br />
<br />
Let's suppose our firewall web management application has a function that allows an authenticated user to delete a rule specified by its positional number, or all the rules of the configuration if the user enters ‘*’ (quite a dangerous feature, but will make the example more interesting). The delete page is shown next. Let’s suppose that the form – for the sake of simplicity – issues a GET request, which will be of the form<br />
<br />
https://[target]/fwmgt/delete?rule=1<br />
<br />
(to delete rule number one)<br />
<br />
https://[target]/fwmgt/delete?rule=*<br />
<br />
(to delete all rules).<br />
<br />
The example is purposely quite naive, but shows in a simple way the dangers of CSRF.<br />
<br />
<center>[[image:Session Riding Firewall Management.gif]]</center><br />
<br />
Therefore, if we enter the value ‘*’ and press the Delete button the following GET request is submitted.<br />
<br />
https://www.company.example/fwmgt/delete?rule=*<br />
<br />
<br />
with the effect of deleting all firewall rules (and ending up in a possibly inconvenient situation...).<br />
<br />
<center>[[image:Session Riding Firewall Management 2.gif]]</center><br />
<br />
<br />
<br />
Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL https://[target]/fwmgt/delete?rule=*<br />
<br />
or by following a link pointing, directly or via a redirection, to the above URL. Or, again, by accessing an HTML page with an embedded ''img'' tag pointing to the same URL.<br />
<br />
In all of these cases, if the user is currently logged in the firewall management application, the request will succeed and will modify the configuration of the firewall. <br />
<br />
One can imagine attacks targeting sensitive applications and making automatic auction bids, money transfers, orders, changing the configuration of critical software components, etc.<br />
<br />
An interesting thing is that these vulnerabilities may be exercised behind a firewall; i.e., it is sufficient that the link being attacked be reachable by the victim (not directly by the attacker). In particular, it can be any Intranet web server; for example, the firewall management station mentioned before, which is unlikely to be exposed to the Internet. Imagine a CSRF attack targeting an application monitoring a nuclear power plant... Sounds far fetched? Probably, but it is a possibility.<br />
<br />
Self-vulnerable applications, i.e. applications that are used both as attack vector and target (such as web mail applications), make things worse. If such an application is vulnerable, the user is obviously logged in when he reads a message containing a CSRF attack, that can target the web mail application and have it perform actions such as deleting messages, sending messages appearing as sent by the user, etc.<br />
<br />
'''Countermeasures.'''<br />
<br />
The following countermeasures are divided among recommendations to users and to developers.<br />
<br />
<u>Users</u><br />
<br />
Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:<br />
<br />
* Logoff immediately after using a web application<br />
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login<br />
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if you have to do both things at the same machine, do them with separate browsers.<br />
<br />
Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.<br />
<br />
<u>Developers</u><br />
<br />
Add session-related information to the URL. What makes the attack possible is the fact that the session is uniquely identified by the cookie, which is automatically sent by the browser. Having other session-specific information being generated at the URL level makes it difficult to the attacker to know the structure of URLs to attack.<br />
<br />
Other countermeasures, while they do not resolve the issue, contribute to make it harder to exploit.<br />
<br />
Use POST instead of GET. While POST requests may be simulated by means of JavaScript, they make it more complex to mount an attack. The same is true with intermediate confirmation pages (such as: “Are you sure you really want to do this?” type of pages). They can be bypassed by an attacker, although they will make their work a bit more complex. Therefore, do not rely solely on these measures to protect your application. Automatic logout mechanisms somewhat mitigate the exposure to these vulnerabilities, though it ultimately depends on the context (a user who works all day long on a vulnerable web banking application is obviously more at risk than a user who uses the same application occasionally).<br />
<br />
==Black Box testing and example==<br />
<br />
To test black box, you need to know URLs in the restricted (authenticated) area. If you possess valid credentials, you can assume both roles – the attacker and the victim. In this case, you know the URLs to be tested just by browsing around the application.<br />
<br />
Otherwise, if you don’t have valid credentials available, you have to organize a real attack, and so induce a legitimate, logged in user into following an appropriate link. This may involve a substantial level of social engineering.<br />
<br />
Either way, a test case can be constructed as follows:<br />
<br />
* let ''u'' the URL being tested; for example, u = http://www.example.com/action<br />
* build a html page containing the http request referencing url u (specifying all relevant parameters; in case of http GET this is straightforward, while to a POST request you need to resort to some Javascript);<br />
* make sure that the valid user is logged on the application;<br />
* induce him into following the link pointing to the to-be-tested URL (social engineering involved if you cannot impersonate the user yourself);<br />
* observe the result, i.e. check if the web server executed the request.<br />
<br />
==Gray Box testing and example==<br />
<br />
Audit the application to ascertain if its session management is vulnerable. If session management relies only on client side values (information available to the browser), then the application is vulnerable. By “client side values” we mean cookies and HTTP authentication credentials (Basic Authentication and other forms of HTTP authentication; NOT form-based authentication, which is an application-level authentication). For an application to not be vulnerable, it must include session-related information in the URL, in a form of unidentifiable or unpredictable by the user ([3] uses the term ''secret'' to refer to this piece of information).<br />
<br />
Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automatized via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.<br />
<br />
<br />
<br />
<br />
<br />
==References==<br />
'''Whitepapers'''<br><br />
* This issue seems to get rediscovered from time to time, under different names. A history of these vulnerabilities has been reconstructed in: http://www.webappsec.org/lists/websecurity/archive/2005-05/msg00003.html<br />
* Peter W:"Cross-Site Request Forgeries" - http://www.tux.org/~peterw/csrf.txt<br />
* Thomas Schreiber:"Session Riding" - http://www.securenet.de/papers/Session_Riding.pdf<br />
* Oldest known post - http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan<br />
* Cross-site Request Forgery FAQ - http://www.cgisecurity.com/articles/csrf-faq.shtml <br />
<br />
'''Tools'''<br><br />
* Currently there are no automated tools that can be used to test for the presence of CSRF vulnerabilities. However, you may use your favorite spider/crawler tools to acquire knowledge about the application structure and to identify the URLs to test.<br />
<br />
<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=32426Cross-Site Request Forgery (CSRF)2008-06-26T10:34:39Z<p>Fmavituna: /* Prevention measures that do '''NOT''' work */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
==Description==<br />
<br />
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.<br />
<br />
For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.<br />
<br />
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.<br />
<br />
Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.<br />
<br />
Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.<br />
<br />
===Prevention measures that do '''NOT''' work===<br />
<br />
;Using a secret cookie<br />
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.<br />
<br />
;Only accepting POST requests<br />
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request. A simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.<br />
<br />
==Risk Factors==<br />
<br />
<br />
<br />
==Examples==<br />
<br />
===How does the attack work?===<br />
<br />
There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:<br />
<br />
POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1<br />
...<br />
...<br />
...<br />
Content-Length: 19;<br />
<br />
acct=BOB&amount=100<br />
<br />
However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:<br />
<br />
GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1<br />
<br />
Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:<br />
<br />
<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki><br />
<br />
Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following: <br />
<br />
<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki><br />
<br />
Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:<br />
<br />
<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki><br />
<br />
If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.<br />
<br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* [[:Category:Client-side Attacks]]<br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[XSS]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually. <br />
* TBD: Add a per-session nonce to URL and all forms<br />
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms<br />
* TBD: .NET - add session identifier to ViewState with MAC<br />
* Checking HTTP referrer details can help mitigate the attack but does certainly not provide a bullet proof solution. By ensuring the HTTP posts have come from the original site means that the attacks from other sites will not function. However, if the CSRF attack was used in combination with XSS on the original site then this mechanism will not provide any protection.<br />
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1<br />
<br />
<br />
==References==<br />
* [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]<br />
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''<br />
<br />
* [[Testing for CSRF]]<br />
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)<br />
<br />
* [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']<br />
: Overview Paper<br />
<br />
* [http://www.owasp.org/index.php/Image:OWASPAppSecEU2006_RequestRodeo.ppt RequestRodeo: Client Side Protection against Session Riding]<br />
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]<br />
<br />
* [http://www.owasp.org/index.php/CSRF_Guard CSRF Guard]<br />
: A J2EE Filter which appends a unique request token to each form and link in the HTML response<br />
<br />
<br />
[[Category:Exploitation of Authentication]]<br />
[[Category:Embedded Malicious Code]]<br />
[[Category:Spoofing]]</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Project_Information:Sqlibench:Ferruh&diff=31005Project Information:Sqlibench:Ferruh2008-06-11T22:09:55Z<p>Fmavituna: New page: Ferruh has working on web application security for more than five years. He's co-founder of the first web application security company in Turkey, worked with Turkish Police and Army as sec...</p>
<hr />
<div>Ferruh has working on web application security for more than five years. He's co-founder of the first web application security company in Turkey, worked with Turkish Police and Army as security consultant. Currently working in Portcullis CLS as Penetration Tester and Security Researcher in UK/London, also he's OWASP Turkey Chapter Leader.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29826Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T12:03:57Z<p>Fmavituna: /* Description of the Issue */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supportssome extra wildcards such as "[]","[^]","_" and "%".<br><br />
<br />
In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:<br><br />
'''<nowiki>SELECT * FROM Article WHERE Content LIKE '%foo%'</nowiki>'''<br />
<br />
In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.<br><br />
<br />
'''<nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br>'''<br />
<br />
So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:<br><br />
'''<nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki><br>'''<br />
<br />
<br><br />
<br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
<br />
=== Example Attack Inputs ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29825Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T12:00:45Z<p>Fmavituna: /* Brief Summary */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
<br />
=== Example Attack Inputs ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29824Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T12:00:28Z<p>Fmavituna: /* Example Attack Inputs */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
<br />
=== Example Attack Inputs ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br><br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29823Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T12:00:19Z<p>Fmavituna: /* Example Attack Inputs = */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
<br />
=== Example Attack Inputs ===<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29822Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T12:00:11Z<p>Fmavituna: /* Example Search Inputs = */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
<br />
=== Example Attack Inputs ====<br />
* <nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
* <nowiki>'%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54'</nowiki> ''bypasses modsecurity''<br />
* <nowiki>_[r/a)_ _(r/b)_ _(r-d)_</nowiki> <br />
* <nowiki>%n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%</nowiki><br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29820Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T11:58:48Z<p>Fmavituna: /* Black Box testing and example */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
<br />
=== Example Search Inputs ====<br />
<nowiki>'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki><br />
<br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29819Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T11:55:05Z<p>Fmavituna: /* References */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29818Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T11:54:44Z<p>Fmavituna: /* References */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually as well a [[Fuzzing|fuzzer]] can employed to automate this process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29817Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T11:54:21Z<p>Fmavituna: /* References */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
Testing can be done manually as well a [[Fuzzing fuzzer|Fuzzing fuzzer]] can employed to automate this process.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29816Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T11:52:52Z<p>Fmavituna: </p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
* [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]<br />
'''Tools'''<br><br />
...<br></div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29815Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T11:51:31Z<p>Fmavituna: /* Brief Summary */</p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.<br />
<br><br />
<br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
...<br><br />
'''Tools'''<br><br />
...<br></div>Fmavitunahttps://wiki.owasp.org/index.php?title=Testing_for_SQL_Wildcard_Attacks_(OWASP-DS-001)&diff=29814Testing for SQL Wildcard Attacks (OWASP-DS-001)2008-05-26T08:04:59Z<p>Fmavituna: </p>
<hr />
<div>{{Template:OWASP Testing Guide v3}}<br />
<br />
'''This is a draft of a section of the new Testing Guide v3'''<br />
<br />
== Brief Summary ==<br />
<br><br />
..here: we describe in "natural language" what we want to test.<br />
<br><br />
== Description of the Issue == <br />
<br><br />
...here: Short Description of the Issue: Topic and Explanation<br />
<br><br />
== Black Box testing and example ==<br />
'''Testing for Topic X vulnerabilities:''' <br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== Gray Box testing and example == <br />
'''Testing for Topic X vulnerabilities:'''<br><br />
...<br><br />
'''Result Expected:'''<br><br />
...<br><br><br />
== References ==<br />
'''Whitepapers'''<br><br />
...<br><br />
'''Tools'''<br><br />
...<br></div>Fmavitunahttps://wiki.owasp.org/index.php?title=Category:OWASP_Code_Review_Project&diff=25260Category:OWASP Code Review Project2008-02-12T14:34:52Z<p>Fmavituna: /* Code review tool */</p>
<hr />
<div>== Code Review Guide (RC1) Completed ==<br />
The code review guide has been completed and is available here:<br />
http://www.lulu.com/content/1415989<br />
Either as a free PDF or a bound book.<br />
<br />
==Code review tool==<br />
The following link is for a beta code review tool which examines code for keywords discussed in the section "[[First sweep of the code base]]"<br><br />
<br />
you can find it here: <br><br />
http://www.cyphersec.com/software_archive/CodeCrawler.rar It's a lightweight tool and undergoing constant development.<br><br />
<br />
== Spring Of Code 2007 ==<br />
The Code review guide is proudly sponsored by the OWASP Spring of Code (SpOC) 2007.<br />
For more information please see http://www.owasp.org/index.php/OWASP_Spring_Of_Code_2007<br />
== Project Contributors ==<br />
<br />
The OWASP Code Review project was concieved by Eoin Keary the OWASP Ireland Founder and Chapter Lead.<br />
We are actively seeking techies to add new sections as new web technologies emerge. <br />
If you are interested in volunteering for the project, or have a comment, question, or suggestion, please drop me a line mailto:eoin.keary@owasp.org<br />
<br />
==Volunteers Needed==<br />
<br />
Yes please, drop me a line.<br />
Need help on this one, don't be shy, all help appreciated<br />
<br />
==Subscribe to the list==<br />
<br />
Go here to subscribe to the maillist.<br />
<br />
http://lists.owasp.org/mailman/listinfo/owasp-codereview<br />
<br />
==Contents==<br />
[[OWASP Code Review Guide Table of Contents]]<br />
<br />
==Roadmap==<br />
<br />
View the [[OWASP Code Review Project Roadmap]]<br />
<br />
[[Category:OWASP Project]]</div>Fmavitunahttps://wiki.owasp.org/index.php?title=What_do_you_want_OWASP_to_be&diff=23360What do you want OWASP to be2007-11-13T11:32:42Z<p>Fmavituna: </p>
<hr />
<div>This page contains is a place holder for OWASP leader's responses to the following question:<br />
<br />
== Question == <br />
<br />
'''OWASP project leaders, chapter leaders and members, as it grows what do you want OWASP to become?'''<br />
<br />
* A certifying and CBK type pseudo-company like (ISC)2?<br />
* An open source project organized along the lines of Debian, Apache, or a similar group that owns a set of projects?<br />
* Does OWASP want to certify apps, testers, both or none? (I've seen all POV advocated)<br />
* Who will be required to pay what kind of dues, if any?<br />
* How formal of an organization will OWASP become?<br />
* Is the status quo preferable to the proposed change?<br />
* Other?<br />
<br />
For the newer members of this list, here are some pages which you might find interesting:<br />
<br />
* [[About_OWASP]]<br />
* [[How_OWASP_Works]]<br />
* [[OWASP_brand_usage_rules]]<br />
* [[Chapter_Rules]]<br />
* [[Chapter_Leader_Handbook]]<br />
* [[:Category:Chapter_Resources]]<br />
* [[Tutorial]]<br />
* [[OWASP_Education_Presentation]]<br />
<br />
== Answers ==<br />
(Please add your local chapter and put your comments under your local chapter heading)<br />
<br />
===CHAPTERS===<br />
<br />
====NY/NJ Metro====<br />
* A certifying and CBK type pseudo-company like (ISC)2? - That is one area to explore or partner with existing SANS as a example.<br />
<br />
* An open source project organized along the lines of Debian, Apache, or a similar group that owns a set of projects? - YES<br />
<br />
* Does OWASP want to certify apps, testers, both or none? (I've seen all POV advocated)- Need more information on how this would work.<br />
<br />
* Who will be required to pay what kind of dues, if any? - All persons who want to be "members" $100.00 per per person is a dontation that is a tax write-off + is skin in the game. <br />
<br />
* How formal of an organization will OWASP become? Subject matter experts, elected board of directors 2 year terms with global mission for the membership.<br />
<br />
* Is the status quo preferable to the proposed change? - OWASP wants to grow and like any small company to do so, some things need to grow as well with milestones to success.<br />
<br />
<br />
====Belgium====<br />
Nov-1 - Pending comments from Belgium mailing members and board members<br />
<br />
Nov-7: (compiled reactions)<br />
<br />
Mostly agree with points mentioned by the Education project leader(see below)<br />
<br />
*''Certifying like (ISC)2'': No, it's too formal, too american and too expensive.<br />
*''An open source project'': For source code / publications it is great to have an open source organisation but for the rest it's more about communication. <br />
*''Does OWASP want to certify apps, testers, both or none'': Who will certify the application? It's more like do you follow the guidelines: Yes/No? And what about software evolution, OWASP needs to setup a complex mechanism to check apps, approve them, re-check them if any new security issue is discovered... Beside that it's part of some people jobs description and they cannot be competitor with the company they are working for?<br />
*''How formal of an organization will OWASP become'': Anarchy is famous for his ability to quickly react because anyone can decide to react... organisation means limitation, conciliation, responsabilities, papers, we all already have jobs/life including all that ... Let's decide some rules that we should not break (- do not display 0 day attack, - do not limit on one technology only, - do not add more "do not" :-)) <br />
*''Is the status quo preferable to the proposed change'':No<br />
<br />
====Helsinki, Finland====<br />
Nov-1 - Waiting for comments from mailing list members<br />
<br />
Nov-9 Compiled Answers from mailing list members<br />
<br />
''A certifying and CBK type pseudo-company like (ISC)2?''<br />
<br />
* No but maybe it should be wise to seek some co-operation with certifying organizations<br />
<br />
''An open source project organized along the lines of Debian, Apache, or a similar group that owns a set of projects?''<br />
<br />
* Open source projects should be part of OWASP but other activities are needed. <br />
<br />
''Does OWASP want to certify apps, testers, both or none? (I've seen all POV advocated)''<br />
<br />
* Rather not<br />
<br />
''Who will be required to pay what kind of dues, if any?''<br />
<br />
* Current system is working.<br />
<br />
''How formal of an organization will OWASP become?''<br />
<br />
* Some increase in formality is perhaps needed to increase visibility. Independence and openess should be retained.<br />
<br />
''Other?''<br />
<br />
* OWASP should be more on the hands of developers than security people. Also more alignment with other domains of security would be beneficial for getting the message through in companies.<br />
<br />
<br />
<br />
====Turkey====<br />
<br />
* Certification is not required. It requires lots of resources and it’s way too commercial.<br />
* Apache Foundation is a good example but also we believe OWASP should not turn into a software development based organization.<br />
*–<br />
* Only “members” should pay money, not project leaders and chapter leaders. Requesting money from chapter leaders or project leader is unacceptable. Since they already spent lots of their time for OWASP.<br />
* Current state of OWASP is quite all right. Making it more formal potentially not going to work and even in this state lots of chapters and chapter leaders are not active enough. Getting more formal is not going to help it either.<br />
* There are some recommendations:<br />
** Generally we want changes, it’s good.<br />
** Active chapters should be supported more and we should start to eliminate inactive chapters.<br />
<br />
<br />
===PROJECTS===<br />
<br />
====Education====<br />
Put forward by Seba:<br />
* I do not think OWASP is the right place to perform certifications. It makes us ‘lawmaker’ and judge at the same time. What OWASP could/should do is propose a certification scheme / criteria input for other parties. This is even a project: http://www.owasp.org/index.php/SpoC_007_-_The_OWASP_Web_Security_Certification_Framework ?<br />
* Organization wise, I like the [http://www.apache.org/foundation/how-it-works.html http://www.apache.org/foundation/how-it-works.html]. The organization should not be the goal: it is there to support achieving the goals. My vote for Apache like organization: +1<br />
* OWASP has been driven by volunteers, who invest personal time: that is worth far more than a membership fee. Let’s keep this separated.<br />
* Over-regulation kills creativity and scares volunteers away. We should keep it very easy for people to start new projects or new chapters. When the projects/chapters grow, the contributing people and project leader(s) can regulate themselves if it is necessary to guarantee continuity. By providing some practical how-to’s and working examples instead of rules, OWASP provides the framework for successful projects/chapters.<br />
* Some projects and chapters will ‘die’: how do we detect this and make this visible? It should be clear for OWASP users/visitors what the project / chapter status is.Define a few measurable criteria that taken together provide a good insight in the project/chapter status.<br />
<br />
====Java Project====<br />
* The Top 10 has been widely misused and misquoted as a Web Application Security Standard. This obviously indicates that a standard is what the industry is looking for. Re-working the sec. dev. guide and the top 10 project to produce a set of web app standards would be an excellent start. But, I don't think it is OWASP's role to verify compliance with, or to certify applications/products with these standards - as that would open a huge can of worms and require considerable changes to how OWASP is funded and staffed.<br />
* The same approach as above could be applied to other aspects of app security, such as secure development. I.e. create the standards formally and provide resources around their implementation, but don't actually certify applications.<br />
* Continue to grow the wiki idea of security sharing for application. OWASP is becoming the primary source of security information for web app vulns. The more developers and security experts start to view and update the OWASP site, the better.<br />
<br />
* Continue the focus on OWASP top 10 and other studies of web vulns. These top 10 lists/studies/reports are being used within company and professional presentations and credit is given to OWASP as the official source of web app info.<br />
<br />
*I think OWASP should offer some sort of professional certification. Perhaps it can be part of the OWASP conferences. Provide some sort of certification for the training tracks which are offered. These tracks are sources of great information which is specific to a technology. Why not offer either a certificate of completion or a test and certification? In my opinion, certifications from well known organizations will significantly drive conference attendance. (One reason why sans does so well)<br />
<br />
* It would be interesting to explore the idea of certifying an app. I can envision the OWASP stamp of approval for an item that has been developed securely (whitebox) and passes all blackbox security tests throughout the development cycle.<br />
<br />
* Charge for conference attendance, sponsorship, certifications, product certifications<br />
* Charge for vendor attendance at conferences<br />
* I like the current idea of membership which provides the benefit for commercial license of OWASP projects. I think that's a good idea to continue pushing, especially as the OWASP project keep growing.<br />
<br />
====Orizon====<br />
I think that as long as Owasp growns up it must follow other Opensource community approach. I mean that having a set of projects and creating like Apache, Debian, OpenBSD does is the right path.<br />
<br />
In my opinion, Owasp doesn't have to become a certification authority instead it could offer security reviews on demand.<br />
A fee could be applied to commercial projects and the collected fees could be used in events such as Spoc, Aoc and conferences, meanwhile these services would be free of charge for opensource projects.<br />
<br />
I think vendors have to pay for being sponsored in Owasp site and Owasp conferences and project and chapter leaders have to be paying owasp member.<br />
<br />
Of course, just my 2 cents</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Category:OWASP_WeBekci_Project&diff=17736Category:OWASP WeBekci Project2007-04-05T10:34:34Z<p>Fmavituna: /* Documents */</p>
<hr />
<div>== What is WeBekci? ==<br />
WeBekci is a web based ModSecurity 2.x management tool. WeBekci is written in PHP, Its backend is powered by MySQL and the frontend by XAJAX framework. It is an OWASP Project.<br />
<br />
== What is ModSecurity for Apache? ==<br />
With over 70% of all attacks now carried out over the web application level, organisations need every help they can get in making their systems secure. Web application firewalls are deployed to establish an external security layer that increases security, detects, and prevents attacks before they reach web applications<br />
[http://www.modsecurity.org (ModSecurity).]<br />
<br />
== Goals ==<br />
It will remove management overhead of ModSecurity 2.x. You can configure modsecurity.conf, add special rules and watch system, apache and modsecurity logs (only guardianlog has been implemented in this version).<br />
<br />
== Features ==<br />
It covers 90 percent of the ModSecurity 2.x configuration features. Manual- and GUI-based rule managements are supported. It permits to add single-argument rules and it covers 70 percent of the action parameters. It can be used in monitoring system, apache and ModSecurity guardian logs. As of this version the monitoring utility is rather basic and it gives some information about the system.<br />
<br />
== Future Development ==<br />
* '''Configuration : ''' Will add all ModSecurity 2.x configuration parameter <br />
* '''Rule generator: ''' All ModSecurity 2.x variables and actions will be modifiable. It will be possible to add rules using multiple variables. Defining chain rules will also be possible.<br />
* '''Logging: ''' ModSecurity`s auditlog and debuglog will be presented in more understandable formats; it will support multi apache error and access logs.<br />
* '''Multiple-DB: ''' Will add PostgreSQL and SQLite support.<br />
<br />
[[Image:webekci.gif|thumb|350px|right]]<br />
<br />
== Requirement == <br />
<br />
* Platform Linux/Unix,<br />
* Apache + ModSecurty 2.x <br />
* Php<br />
* Mysql<br />
<br />
== News ==<br />
'''OWASP WeBekci Project Release! - 31 March 2007 '''<br />
<br />
== Installation== <br />
<br />
Download adress: http://sourceforge.net/projects/webekci/<br />
<br />
# tar –zxvf webekci-1.0.tar.gz<br />
# mv webekci /usr/local/www/<br />
# cd /usr/local/www/webekci<br />
<br />
Primarily, create .htaccess and .htpasswd files. These are required for WeBekci`s own. <br />
Edit .htaccess file:<br />
<br />
# vi .htaccess <br />
<br />
In the .htaccess file, enter the correct path for the .htpasswd file in the AuthUserFile line in accordance with your own configuration:<br />
<br />
AuthUserFile /usr/home/bunyamin/.htpasswd<br />
AuthType Basic<br />
AuthName "Owasp-WeBekci Screet Area"<br />
<LIMIT GET POST><br />
require valid-user<br />
</LIMIT><br />
<br />
Now edit .htpasswd file:<br />
<br />
# vi .htpasswd<br />
<br />
If the user name is going to be “webekci” and password “1234”, then enter:<br />
<br />
webekci:cwc9eWGIM9r5M<br />
<br />
You may enter your own UID and password.<br />
<br />
<br />
Now, you need define “directory” in the httpd.conf file.<br />
<br />
Alias /webekci/ "/usr/local/www/webekci/"<br />
<Directory "/usr/local/www/webekci/"><br />
Options None<br />
AllowOverride All<br />
Order Allow,Deny<br />
Allow from all<br />
</Directory><br />
<br />
Note: If you are using mod_rewrite, then enter “AllowOverride All” so that .htaccess file can be read. Otherwise enter “AllowOverride None”.<br />
<br />
# apachectl restart<br />
<br />
Make necessary modifications in config.php file. Add the following line:<br />
<br />
$config['modsecurity_conf']='/usr/local/etc/apache22/extra/mod_security.conf';<br />
<br />
It’s important to create the mod_security.conf file and include its path to the httpd.conf. Let’s add the following line into your httpd.conf. Change the path according to your distribution if necessary.<br />
<br />
Include etc/apache22/extra/mod_security.conf<br />
<br />
To give the www user read and write permissions:<br />
<br />
# chown www /usr/local/etc/apache22/extra/mod_security.conf<br />
<br />
Note: www user is the user where apache runs. Please check the the following entries in httpd.conf: <br />
<br />
User www<br />
<br />
Group www<br />
<br />
Some distributions may have different user and/or group names.<br />
<br />
After configuring WeBekci you need to restart apache. Do this with these sudo configurations:<br />
$config['apache_config_test'] = '/usr/local/bin/sudo /usr/local/sbin/httpd -t';<br />
<br />
$config['apache_restart']='/usr/local/bin/sudo /usr/local/sbin/httpd -k restart';<br />
<br />
Also alter your config.php according to your distro. Edit sudoers file:<br />
<br />
# vi /usr/local/etc/sudoers<br />
<br />
Enter these lines:<br />
<br />
www ALL=NOPASSWD:/usr/local/sbin/httpd -k restart<br />
www ALL=NOPASSWD:/usr/local/sbin/httpd -t<br />
<br />
Now www user can do “config test” and “restart” operations restart apache without having to enter password.<br />
<br />
Please make sure you entered MySQL related changes in your config.php file; and browse your site and run the install.php file:<br />
<br />
http://www.site.com/webekci/install.php<br />
<br />
Do not forget to delete install.php later..<br />
<br />
# rm install.php<br />
<br />
A reminder: www user must have read-write rights to audit, debug and guardian log files. For instance, if the Guardian log file has the path as “/var/log/modsec_guardian.log” , then we need to enter this command:<br />
<br />
# chown www /var/log/modsec_guardian.log<br />
<br />
Now the guardian log can be seen in the program. You have to do chown for other log files, too.<br />
<br />
I express my gratitude to those who helped me with this write-up.<br />
<br />
<br />
== Project Contributor ==<br />
The project is lead by * [[User:Bunyamin|Bunyamin Demir]] (bunyamin~owasp.org)<br />
<br />
Mail list: owasp-webekci~lists.owasp.org<br />
<br />
== Documents ==<br />
ModSecurity 2.1.0 Reference documentation [http://www.modsecurity.org/documentation/modsecurity-apache/2.1.0/modsecurity2-apache-reference.pdf (English)] [http://www.modsecurity.org/documentation/contributed/ModSecurity_2.1.0_Turkish.pdf (Turkish)]<br />
<br />
<br />
WeBekci documentation [[Media:Owasp-webekci-1.0_en.doc |(English)]] [[Media:Owasp-webekci-1.0_tr.doc |(Turkish)]]<br />
<br />
== Project Sponsor ==<br />
If you would like to help WeBekci project development, feel free to contact the project leader.</div>Fmavitunahttps://wiki.owasp.org/index.php?title=Category:OWASP_WeBekci_Project&diff=17735Category:OWASP WeBekci Project2007-04-05T10:34:20Z<p>Fmavituna: /* Project Sponsor */</p>
<hr />
<div>== What is WeBekci? ==<br />
WeBekci is a web based ModSecurity 2.x management tool. WeBekci is written in PHP, Its backend is powered by MySQL and the frontend by XAJAX framework. It is an OWASP Project.<br />
<br />
== What is ModSecurity for Apache? ==<br />
With over 70% of all attacks now carried out over the web application level, organisations need every help they can get in making their systems secure. Web application firewalls are deployed to establish an external security layer that increases security, detects, and prevents attacks before they reach web applications<br />
[http://www.modsecurity.org (ModSecurity).]<br />
<br />
== Goals ==<br />
It will remove management overhead of ModSecurity 2.x. You can configure modsecurity.conf, add special rules and watch system, apache and modsecurity logs (only guardianlog has been implemented in this version).<br />
<br />
== Features ==<br />
It covers 90 percent of the ModSecurity 2.x configuration features. Manual- and GUI-based rule managements are supported. It permits to add single-argument rules and it covers 70 percent of the action parameters. It can be used in monitoring system, apache and ModSecurity guardian logs. As of this version the monitoring utility is rather basic and it gives some information about the system.<br />
<br />
== Future Development ==<br />
* '''Configuration : ''' Will add all ModSecurity 2.x configuration parameter <br />
* '''Rule generator: ''' All ModSecurity 2.x variables and actions will be modifiable. It will be possible to add rules using multiple variables. Defining chain rules will also be possible.<br />
* '''Logging: ''' ModSecurity`s auditlog and debuglog will be presented in more understandable formats; it will support multi apache error and access logs.<br />
* '''Multiple-DB: ''' Will add PostgreSQL and SQLite support.<br />
<br />
[[Image:webekci.gif|thumb|350px|right]]<br />
<br />
== Requirement == <br />
<br />
* Platform Linux/Unix,<br />
* Apache + ModSecurty 2.x <br />
* Php<br />
* Mysql<br />
<br />
== News ==<br />
'''OWASP WeBekci Project Release! - 31 March 2007 '''<br />
<br />
== Installation== <br />
<br />
Download adress: http://sourceforge.net/projects/webekci/<br />
<br />
# tar –zxvf webekci-1.0.tar.gz<br />
# mv webekci /usr/local/www/<br />
# cd /usr/local/www/webekci<br />
<br />
Primarily, create .htaccess and .htpasswd files. These are required for WeBekci`s own. <br />
Edit .htaccess file:<br />
<br />
# vi .htaccess <br />
<br />
In the .htaccess file, enter the correct path for the .htpasswd file in the AuthUserFile line in accordance with your own configuration:<br />
<br />
AuthUserFile /usr/home/bunyamin/.htpasswd<br />
AuthType Basic<br />
AuthName "Owasp-WeBekci Screet Area"<br />
<LIMIT GET POST><br />
require valid-user<br />
</LIMIT><br />
<br />
Now edit .htpasswd file:<br />
<br />
# vi .htpasswd<br />
<br />
If the user name is going to be “webekci” and password “1234”, then enter:<br />
<br />
webekci:cwc9eWGIM9r5M<br />
<br />
You may enter your own UID and password.<br />
<br />
<br />
Now, you need define “directory” in the httpd.conf file.<br />
<br />
Alias /webekci/ "/usr/local/www/webekci/"<br />
<Directory "/usr/local/www/webekci/"><br />
Options None<br />
AllowOverride All<br />
Order Allow,Deny<br />
Allow from all<br />
</Directory><br />
<br />
Note: If you are using mod_rewrite, then enter “AllowOverride All” so that .htaccess file can be read. Otherwise enter “AllowOverride None”.<br />
<br />
# apachectl restart<br />
<br />
Make necessary modifications in config.php file. Add the following line:<br />
<br />
$config['modsecurity_conf']='/usr/local/etc/apache22/extra/mod_security.conf';<br />
<br />
It’s important to create the mod_security.conf file and include its path to the httpd.conf. Let’s add the following line into your httpd.conf. Change the path according to your distribution if necessary.<br />
<br />
Include etc/apache22/extra/mod_security.conf<br />
<br />
To give the www user read and write permissions:<br />
<br />
# chown www /usr/local/etc/apache22/extra/mod_security.conf<br />
<br />
Note: www user is the user where apache runs. Please check the the following entries in httpd.conf: <br />
<br />
User www<br />
<br />
Group www<br />
<br />
Some distributions may have different user and/or group names.<br />
<br />
After configuring WeBekci you need to restart apache. Do this with these sudo configurations:<br />
$config['apache_config_test'] = '/usr/local/bin/sudo /usr/local/sbin/httpd -t';<br />
<br />
$config['apache_restart']='/usr/local/bin/sudo /usr/local/sbin/httpd -k restart';<br />
<br />
Also alter your config.php according to your distro. Edit sudoers file:<br />
<br />
# vi /usr/local/etc/sudoers<br />
<br />
Enter these lines:<br />
<br />
www ALL=NOPASSWD:/usr/local/sbin/httpd -k restart<br />
www ALL=NOPASSWD:/usr/local/sbin/httpd -t<br />
<br />
Now www user can do “config test” and “restart” operations restart apache without having to enter password.<br />
<br />
Please make sure you entered MySQL related changes in your config.php file; and browse your site and run the install.php file:<br />
<br />
http://www.site.com/webekci/install.php<br />
<br />
Do not forget to delete install.php later..<br />
<br />
# rm install.php<br />
<br />
A reminder: www user must have read-write rights to audit, debug and guardian log files. For instance, if the Guardian log file has the path as “/var/log/modsec_guardian.log” , then we need to enter this command:<br />
<br />
# chown www /var/log/modsec_guardian.log<br />
<br />
Now the guardian log can be seen in the program. You have to do chown for other log files, too.<br />
<br />
I express my gratitude to those who helped me with this write-up.<br />
<br />
<br />
== Project Contributor ==<br />
The project is lead by * [[User:Bunyamin|Bunyamin Demir]] (bunyamin~owasp.org)<br />
<br />
Mail list: owasp-webekci~lists.owasp.org<br />
<br />
== Documents ==<br />
ModSecurity 2.1.0 Reference documentation [http://www.modsecurity.org/documentation/modsecurity-apache/2.1.0/modsecurity2-apache-reference.pdf (English)] [http://www.modsecurity.org/documentation/contributed/ModSecurity_2.1.0_Turkish.pdf (Turkish)]<br />
<br />
<br />
WeBekci ducumentation [[Media:Owasp-webekci-1.0_en.doc |(English)]] [[Media:Owasp-webekci-1.0_tr.doc |(Turkish)]]<br />
<br />
<br />
== Project Sponsor ==<br />
If you would like to help WeBekci project development, feel free to contact the project leader.</div>Fmavituna