The following server-side pseudo-code is used to authenticate users to the web application.
 # Define POST variables uname = request.POST['username'] passwd = request.POST['password']  # SQL query vulnerable to SQLi sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"  # Execute the SQL statement database.execute(sql)
The above script is a simple example of authenticating a user with a username and a password against a database with a table named users, and a username and password column.

The above script is vulnerable to SQL injection because an attacker could submit malicious input in such a way that would alter the SQL statement being executed by the database server.

A simple example of an SQL injection payload could be something as simple as setting the password field to password' OR 1=1.

This would result in the following SQL query being run against the database server.
 SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query further.
 -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite ' OR '1'='1' -- ' OR '1'='1' /* -- MySQL ' OR '1'='1' # -- Access (using null characters) ' OR '1'='1' %00 ' OR '1'='1' %16
Once the query executes, the result is returned to the application to be processed, resulting in an authentication bypass. In the event of authentication bypass being possible, the application will most likely log the attacker in with the first account from the query result — the first account in a database is usually of an administrative user.

What's the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run commands on the operating system from an SQL statement.

Keeping the above in mind, when considering the following, it's easier to understand how lucrative a successful SQL injection attack can be for an attacker.

  • An attacker can use SQL injection to bypass authentication or even impersonate specific users.
  • One of SQL's primary functions is to select data based on a query and output the result of that query. An SQL injection vulnerability could allow the complete disclosure of data residing on a database server.
  • Since web applications use SQL to alter data within a database, an attacker could use SQL injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
  • SQL is used to delete records from a database. An attacker could use an SQL injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application's availability until the database is restored.
  • Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL injection as the initial vector in an attack of an internal network that sits behind a firewall.

Preventing SQL injection using parameterized queries
SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both the programming languages, as well as the RDBMSs themselves have evolved to provide web application developers with a way to safely query the database — parameterized SQL queries.

Parameterized queries are simple to write and understand while forcing a developer to define the entire SQL statement before hand, using placeholders for the actual variables within that statement. A developer would then pass in each parameter to the query after the SQL statement is defined, allowing the database to be able to distinguish between the SQL command and data inputted by a user. If SQL commands are inputted by an attacker, the parameterized query would treat the input as a string as opposed to an SQL command.

Application developers should avoid sanitizing their input by means of escaping or removing special characters (several encoding tricks an attacker could leverage to bypass such protections) and stick to using parameterized queries in order to avoid SQL injection vulnerabilities.]]>

The following server-side pseudo-code is used to authenticate users to the web application.
 # Define POST variables uname = request.POST['username'] passwd = request.POST['password']  # SQL query vulnerable to SQLi sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"  # Execute the SQL statement database.execute(sql)
The above script is a simple example of authenticating a user with a username and a password against a database with a table named users, and a username and password column.

The above script is vulnerable to SQL injection because an attacker could submit malicious input in such a way that would alter the SQL statement being executed by the database server.

A simple example of an SQL injection payload could be something as simple as setting the password field to password' OR 1=1.

This would result in the following SQL query being run against the database server.
 SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query further.
 -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite ' OR '1'='1' -- ' OR '1'='1' /* -- MySQL ' OR '1'='1' # -- Access (using null characters) ' OR '1'='1' %00 ' OR '1'='1' %16
Once the query executes, the result is returned to the application to be processed, resulting in an authentication bypass. In the event of authentication bypass being possible, the application will most likely log the attacker in with the first account from the query result — the first account in a database is usually of an administrative user.

What's the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run commands on the operating system from an SQL statement.

Keeping the above in mind, when considering the following, it's easier to understand how lucrative a successful SQL injection attack can be for an attacker.

  • An attacker can use SQL injection to bypass authentication or even impersonate specific users.
  • One of SQL's primary functions is to select data based on a query and output the result of that query. An SQL injection vulnerability could allow the complete disclosure of data residing on a database server.
  • Since web applications use SQL to alter data within a database, an attacker could use SQL injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
  • SQL is used to delete records from a database. An attacker could use an SQL injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application's availability until the database is restored.
  • Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL injection as the initial vector in an attack of an internal network that sits behind a firewall.

Preventing SQL injection using parameterized queries
SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both the programming languages, as well as the RDBMSs themselves have evolved to provide web application developers with a way to safely query the database — parameterized SQL queries.

Parameterized queries are simple to write and understand while forcing a developer to define the entire SQL statement before hand, using placeholders for the actual variables within that statement. A developer would then pass in each parameter to the query after the SQL statement is defined, allowing the database to be able to distinguish between the SQL command and data inputted by a user. If SQL commands are inputted by an attacker, the parameterized query would treat the input as a string as opposed to an SQL command.

Application developers should avoid sanitizing their input by means of escaping or removing special characters (several encoding tricks an attacker could leverage to bypass such protections) and stick to using parameterized queries in order to avoid SQL injection vulnerabilities.]]>

Furthermore, JavaScript can read and make arbitrary modifications to the contents of a page being displayed to a user. Therefore, XSS in conjunction with some clever social engineering opens up a lot of possibilities for an attacker.]]>
Since cross-site scripting (XSS) is user input which is interpreted as code. In order to prevent XSS, secure input handling is necessary. The two fundamental methods of handling untrusted user input are encoding and validation.

  • Encoding - Escapes user input so that browsers interpret it as data, not as code
  • Validation - Filters user input so that browsers interpret it as code without malicious commands

Encoding and validation are two different techniques to preventing cross-site scripting (XSS). Deciding which should be used highly depends on the context within which the untrusted user input is being inserted.

The following are two examples of the most common cross-site scripting (XSS) contexts.
 <!-- HTML element --> <div>userInput</div>  <!-- HTML attribute --> <input value="userInput">
The method for preventing cross-site (XSS) scripting in the two examples above is different. In the first example, where user input is inserted in an HTML element, HTML encoding is the correct way to prevent XSS. However, in the second example, where user input is inserted in an HTML attribute, validation (in this case, filtering out ' and ")is the appropriate prevention method.
 <!-- Application code --> <input value="userInput">  <!-- Malicious string --> "><script>...</script><input value="  <!-- Resulting code --> <input value=""><script>...</script><input value="">
In most of the time, encoding should be performed whenever user input is included in a page, however, as with the above example, in some cases, encoding has to be replaced by or complemented with validation.

It's important to remember that secure input handling has to take into account which context of a page the user input is inserted into.]]>

Furthermore, JavaScript can read and make arbitrary modifications to the contents of a page being displayed to a user. Therefore, XSS in conjunction with some clever social engineering opens up a lot of possibilities for an attacker.]]>
Since cross-site scripting (XSS) is user input which is interpreted as code. In order to prevent XSS, secure input handling is necessary. The two fundamental methods of handling untrusted user input are encoding and validation.

  • Encoding - Escapes user input so that browsers interpret it as data, not as code
  • Validation - Filters user input so that browsers interpret it as code without malicious commands

Encoding and validation are two different techniques to preventing cross-site scripting (XSS). Deciding which should be used highly depends on the context within which the untrusted user input is being inserted.

The following are two examples of the most common cross-site scripting (XSS) contexts.
 <!-- HTML element --> <div>userInput</div>  <!-- HTML attribute --> <input value="userInput">
The method for preventing cross-site (XSS) scripting in the two examples above is different. In the first example, where user input is inserted in an HTML element, HTML encoding is the correct way to prevent XSS. However, in the second example, where user input is inserted in an HTML attribute, validation (in this case, filtering out ' and ")is the appropriate prevention method.
 <!-- Application code --> <input value="userInput">  <!-- Malicious string --> "><script>...</script><input value="  <!-- Resulting code --> <input value=""><script>...</script><input value="">
In most of the time, encoding should be performed whenever user input is included in a page, however, as with the above example, in some cases, encoding has to be replaced by or complemented with validation.

It's important to remember that secure input handling has to take into account which context of a page the user input is inserted into.]]>

Furthermore, JavaScript can read and make arbitrary modifications to the contents of a page being displayed to a user. Therefore, XSS in conjunction with some clever social engineering opens up a lot of possibilities for an attacker.]]>
Since cross-site scripting (XSS) is user input which is interpreted as code. In order to prevent XSS, secure input handling is necessary. The two fundamental methods of handling untrusted user input are encoding and validation.

  • Encoding - Escapes user input so that browsers interpret it as data, not as code
  • Validation - Filters user input so that browsers interpret it as code without malicious commands

Encoding and validation are two different techniques to preventing cross-site scripting (XSS). Deciding which should be used highly depends on the context within which the untrusted user input is being inserted.

The following are two examples of the most common cross-site scripting (XSS) contexts.
 <!-- HTML element --> <div>userInput</div>  <!-- HTML attribute --> <input value="userInput">
The method for preventing cross-site (XSS) scripting in the two examples above is different. In the first example, where user input is inserted in an HTML element, HTML encoding is the correct way to prevent XSS. However, in the second example, where user input is inserted in an HTML attribute, validation (in this case, filtering out ' and ")is the appropriate prevention method.
 <!-- Application code --> <input value="userInput">  <!-- Malicious string --> "><script>...</script><input value="  <!-- Resulting code --> <input value=""><script>...</script><input value="">
In most of the time, encoding should be performed whenever user input is included in a page, however, as with the above example, in some cases, encoding has to be replaced by or complemented with validation.

It's important to remember that secure input handling has to take into account which context of a page the user input is inserted into.]]>

Furthermore, JavaScript can read and make arbitrary modifications to the contents of a page being displayed to a user. Therefore, XSS in conjunction with some clever social engineering opens up a lot of possibilities for an attacker.]]>
Since cross-site scripting (XSS) is user input which is interpreted as code. In order to prevent XSS, secure input handling is necessary. The two fundamental methods of handling untrusted user input are encoding and validation.

  • Encoding - Escapes user input so that browsers interpret it as data, not as code
  • Validation - Filters user input so that browsers interpret it as code without malicious commands

Encoding and validation are two different techniques to preventing cross-site scripting (XSS). Deciding which should be used highly depends on the context within which the untrusted user input is being inserted.

The following are two examples of the most common cross-site scripting (XSS) contexts.
 <!-- HTML element --> <div>userInput</div>  <!-- HTML attribute --> <input value="userInput">
The method for preventing cross-site (XSS) scripting in the two examples above is different. In the first example, where user input is inserted in an HTML element, HTML encoding is the correct way to prevent XSS. However, in the second example, where user input is inserted in an HTML attribute, validation (in this case, filtering out ' and ")is the appropriate prevention method.
 <!-- Application code --> <input value="userInput">  <!-- Malicious string --> "><script>...</script><input value="  <!-- Resulting code --> <input value=""><script>...</script><input value="">
In most of the time, encoding should be performed whenever user input is included in a page, however, as with the above example, in some cases, encoding has to be replaced by or complemented with validation.

It's important to remember that secure input handling has to take into account which context of a page the user input is inserted into.]]>

Furthermore, JavaScript can read and make arbitrary modifications to the contents of a page being displayed to a user. Therefore, XSS in conjunction with some clever social engineering opens up a lot of possibilities for an attacker.]]>
Since cross-site scripting (XSS) is user input which is interpreted as code. In order to prevent XSS, secure input handling is necessary. The two fundamental methods of handling untrusted user input are encoding and validation.

  • Encoding - Escapes user input so that browsers interpret it as data, not as code
  • Validation - Filters user input so that browsers interpret it as code without malicious commands

Encoding and validation are two different techniques to preventing cross-site scripting (XSS). Deciding which should be used highly depends on the context within which the untrusted user input is being inserted.

The following are two examples of the most common cross-site scripting (XSS) contexts.
 <!-- HTML element --> <div>userInput</div>  <!-- HTML attribute --> <input value="userInput">
The method for preventing cross-site (XSS) scripting in the two examples above is different. In the first example, where user input is inserted in an HTML element, HTML encoding is the correct way to prevent XSS. However, in the second example, where user input is inserted in an HTML attribute, validation (in this case, filtering out ' and ")is the appropriate prevention method.
 <!-- Application code --> <input value="userInput">  <!-- Malicious string --> "><script>...</script><input value="  <!-- Resulting code --> <input value=""><script>...</script><input value="">
In most of the time, encoding should be performed whenever user input is included in a page, however, as with the above example, in some cases, encoding has to be replaced by or complemented with validation.

It's important to remember that secure input handling has to take into account which context of a page the user input is inserted into.]]>

Directory Traversal is a vulnerability which allows attackers to access restricted directories and read files outside of the web server's root directory.]]>

The following server-side pseudo-code is used to authenticate users to the web application.
 # Define POST variables uname = request.POST['username'] passwd = request.POST['password']  # SQL query vulnerable to SQLi sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"  # Execute the SQL statement database.execute(sql)
The above script is a simple example of authenticating a user with a username and a password against a database with a table named users, and a username and password column.

The above script is vulnerable to SQL injection because an attacker could submit malicious input in such a way that would alter the SQL statement being executed by the database server.

A simple example of an SQL injection payload could be something as simple as setting the password field to password' OR 1=1.

This would result in the following SQL query being run against the database server.
 SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query further.
 -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite ' OR '1'='1' -- ' OR '1'='1' /* -- MySQL ' OR '1'='1' # -- Access (using null characters) ' OR '1'='1' %00 ' OR '1'='1' %16
Once the query executes, the result is returned to the application to be processed, resulting in an authentication bypass. In the event of authentication bypass being possible, the application will most likely log the attacker in with the first account from the query result — the first account in a database is usually of an administrative user.

What's the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run commands on the operating system from an SQL statement.

Keeping the above in mind, when considering the following, it's easier to understand how lucrative a successful SQL injection attack can be for an attacker.

  • An attacker can use SQL injection to bypass authentication or even impersonate specific users.
  • One of SQL's primary functions is to select data based on a query and output the result of that query. An SQL injection vulnerability could allow the complete disclosure of data residing on a database server.
  • Since web applications use SQL to alter data within a database, an attacker could use SQL injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
  • SQL is used to delete records from a database. An attacker could use an SQL injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application's availability until the database is restored.
  • Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL injection as the initial vector in an attack of an internal network that sits behind a firewall.

Preventing SQL injection using parameterized queries
SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both the programming languages, as well as the RDBMSs themselves have evolved to provide web application developers with a way to safely query the database — parameterized SQL queries.

Parameterized queries are simple to write and understand while forcing a developer to define the entire SQL statement before hand, using placeholders for the actual variables within that statement. A developer would then pass in each parameter to the query after the SQL statement is defined, allowing the database to be able to distinguish between the SQL command and data inputted by a user. If SQL commands are inputted by an attacker, the parameterized query would treat the input as a string as opposed to an SQL command.

Application developers should avoid sanitizing their input by means of escaping or removing special characters (several encoding tricks an attacker could leverage to bypass such protections) and stick to using parameterized queries in order to avoid SQL injection vulnerabilities.]]>

The following server-side pseudo-code is used to authenticate users to the web application.
 # Define POST variables uname = request.POST['username'] passwd = request.POST['password']  # SQL query vulnerable to SQLi sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"  # Execute the SQL statement database.execute(sql)
The above script is a simple example of authenticating a user with a username and a password against a database with a table named users, and a username and password column.

The above script is vulnerable to SQL injection because an attacker could submit malicious input in such a way that would alter the SQL statement being executed by the database server.

A simple example of an SQL injection payload could be something as simple as setting the password field to password' OR 1=1.

This would result in the following SQL query being run against the database server.
 SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query further.
 -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite ' OR '1'='1' -- ' OR '1'='1' /* -- MySQL ' OR '1'='1' # -- Access (using null characters) ' OR '1'='1' %00 ' OR '1'='1' %16
Once the query executes, the result is returned to the application to be processed, resulting in an authentication bypass. In the event of authentication bypass being possible, the application will most likely log the attacker in with the first account from the query result — the first account in a database is usually of an administrative user.

What's the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run commands on the operating system from an SQL statement.

Keeping the above in mind, when considering the following, it's easier to understand how lucrative a successful SQL injection attack can be for an attacker.

  • An attacker can use SQL injection to bypass authentication or even impersonate specific users.
  • One of SQL's primary functions is to select data based on a query and output the result of that query. An SQL injection vulnerability could allow the complete disclosure of data residing on a database server.
  • Since web applications use SQL to alter data within a database, an attacker could use SQL injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
  • SQL is used to delete records from a database. An attacker could use an SQL injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application's availability until the database is restored.
  • Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL injection as the initial vector in an attack of an internal network that sits behind a firewall.

Preventing SQL injection using parameterized queries
SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both the programming languages, as well as the RDBMSs themselves have evolved to provide web application developers with a way to safely query the database — parameterized SQL queries.

Parameterized queries are simple to write and understand while forcing a developer to define the entire SQL statement before hand, using placeholders for the actual variables within that statement. A developer would then pass in each parameter to the query after the SQL statement is defined, allowing the database to be able to distinguish between the SQL command and data inputted by a user. If SQL commands are inputted by an attacker, the parameterized query would treat the input as a string as opposed to an SQL command.

Application developers should avoid sanitizing their input by means of escaping or removing special characters (several encoding tricks an attacker could leverage to bypass such protections) and stick to using parameterized queries in order to avoid SQL injection vulnerabilities.]]>

The following server-side pseudo-code is used to authenticate users to the web application.
 # Define POST variables uname = request.POST['username'] passwd = request.POST['password']  # SQL query vulnerable to SQLi sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"  # Execute the SQL statement database.execute(sql)
The above script is a simple example of authenticating a user with a username and a password against a database with a table named users, and a username and password column.

The above script is vulnerable to SQL injection because an attacker could submit malicious input in such a way that would alter the SQL statement being executed by the database server.

A simple example of an SQL injection payload could be something as simple as setting the password field to password' OR 1=1.

This would result in the following SQL query being run against the database server.
 SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query further.
 -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite ' OR '1'='1' -- ' OR '1'='1' /* -- MySQL ' OR '1'='1' # -- Access (using null characters) ' OR '1'='1' %00 ' OR '1'='1' %16
Once the query executes, the result is returned to the application to be processed, resulting in an authentication bypass. In the event of authentication bypass being possible, the application will most likely log the attacker in with the first account from the query result — the first account in a database is usually of an administrative user.

What's the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run commands on the operating system from an SQL statement.

Keeping the above in mind, when considering the following, it's easier to understand how lucrative a successful SQL injection attack can be for an attacker.

  • An attacker can use SQL injection to bypass authentication or even impersonate specific users.
  • One of SQL's primary functions is to select data based on a query and output the result of that query. An SQL injection vulnerability could allow the complete disclosure of data residing on a database server.
  • Since web applications use SQL to alter data within a database, an attacker could use SQL injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
  • SQL is used to delete records from a database. An attacker could use an SQL injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application's availability until the database is restored.
  • Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL injection as the initial vector in an attack of an internal network that sits behind a firewall.

Preventing SQL injection using parameterized queries
SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both the programming languages, as well as the RDBMSs themselves have evolved to provide web application developers with a way to safely query the database — parameterized SQL queries.

Parameterized queries are simple to write and understand while forcing a developer to define the entire SQL statement before hand, using placeholders for the actual variables within that statement. A developer would then pass in each parameter to the query after the SQL statement is defined, allowing the database to be able to distinguish between the SQL command and data inputted by a user. If SQL commands are inputted by an attacker, the parameterized query would treat the input as a string as opposed to an SQL command.

Application developers should avoid sanitizing their input by means of escaping or removing special characters (several encoding tricks an attacker could leverage to bypass such protections) and stick to using parameterized queries in order to avoid SQL injection vulnerabilities.]]>

The following server-side pseudo-code is used to authenticate users to the web application.
 # Define POST variables uname = request.POST['username'] passwd = request.POST['password']  # SQL query vulnerable to SQLi sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"  # Execute the SQL statement database.execute(sql)
The above script is a simple example of authenticating a user with a username and a password against a database with a table named users, and a username and password column.

The above script is vulnerable to SQL injection because an attacker could submit malicious input in such a way that would alter the SQL statement being executed by the database server.

A simple example of an SQL injection payload could be something as simple as setting the password field to password' OR 1=1.

This would result in the following SQL query being run against the database server.
 SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query further.
 -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite ' OR '1'='1' -- ' OR '1'='1' /* -- MySQL ' OR '1'='1' # -- Access (using null characters) ' OR '1'='1' %00 ' OR '1'='1' %16
Once the query executes, the result is returned to the application to be processed, resulting in an authentication bypass. In the event of authentication bypass being possible, the application will most likely log the attacker in with the first account from the query result — the first account in a database is usually of an administrative user.

What's the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run commands on the operating system from an SQL statement.

Keeping the above in mind, when considering the following, it's easier to understand how lucrative a successful SQL injection attack can be for an attacker.

  • An attacker can use SQL injection to bypass authentication or even impersonate specific users.
  • One of SQL's primary functions is to select data based on a query and output the result of that query. An SQL injection vulnerability could allow the complete disclosure of data residing on a database server.
  • Since web applications use SQL to alter data within a database, an attacker could use SQL injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
  • SQL is used to delete records from a database. An attacker could use an SQL injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application's availability until the database is restored.
  • Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL injection as the initial vector in an attack of an internal network that sits behind a firewall.

Preventing SQL injection using parameterized queries
SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both the programming languages, as well as the RDBMSs themselves have evolved to provide web application developers with a way to safely query the database — parameterized SQL queries.

Parameterized queries are simple to write and understand while forcing a developer to define the entire SQL statement before hand, using placeholders for the actual variables within that statement. A developer would then pass in each parameter to the query after the SQL statement is defined, allowing the database to be able to distinguish between the SQL command and data inputted by a user. If SQL commands are inputted by an attacker, the parameterized query would treat the input as a string as opposed to an SQL command.

Application developers should avoid sanitizing their input by means of escaping or removing special characters (several encoding tricks an attacker could leverage to bypass such protections) and stick to using parameterized queries in order to avoid SQL injection vulnerabilities.]]>

The following server-side pseudo-code is used to authenticate users to the web application.
 # Define POST variables uname = request.POST['username'] passwd = request.POST['password']  # SQL query vulnerable to SQLi sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"  # Execute the SQL statement database.execute(sql)
The above script is a simple example of authenticating a user with a username and a password against a database with a table named users, and a username and password column.

The above script is vulnerable to SQL injection because an attacker could submit malicious input in such a way that would alter the SQL statement being executed by the database server.

A simple example of an SQL injection payload could be something as simple as setting the password field to password' OR 1=1.

This would result in the following SQL query being run against the database server.
 SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query further.
 -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite ' OR '1'='1' -- ' OR '1'='1' /* -- MySQL ' OR '1'='1' # -- Access (using null characters) ' OR '1'='1' %00 ' OR '1'='1' %16
Once the query executes, the result is returned to the application to be processed, resulting in an authentication bypass. In the event of authentication bypass being possible, the application will most likely log the attacker in with the first account from the query result — the first account in a database is usually of an administrative user.

What's the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run commands on the operating system from an SQL statement.

Keeping the above in mind, when considering the following, it's easier to understand how lucrative a successful SQL injection attack can be for an attacker.

  • An attacker can use SQL injection to bypass authentication or even impersonate specific users.
  • One of SQL's primary functions is to select data based on a query and output the result of that query. An SQL injection vulnerability could allow the complete disclosure of data residing on a database server.
  • Since web applications use SQL to alter data within a database, an attacker could use SQL injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
  • SQL is used to delete records from a database. An attacker could use an SQL injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application's availability until the database is restored.
  • Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL injection as the initial vector in an attack of an internal network that sits behind a firewall.

Preventing SQL injection using parameterized queries
SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both the programming languages, as well as the RDBMSs themselves have evolved to provide web application developers with a way to safely query the database — parameterized SQL queries.

Parameterized queries are simple to write and understand while forcing a developer to define the entire SQL statement before hand, using placeholders for the actual variables within that statement. A developer would then pass in each parameter to the query after the SQL statement is defined, allowing the database to be able to distinguish between the SQL command and data inputted by a user. If SQL commands are inputted by an attacker, the parameterized query would treat the input as a string as opposed to an SQL command.

Application developers should avoid sanitizing their input by means of escaping or removing special characters (several encoding tricks an attacker could leverage to bypass such protections) and stick to using parameterized queries in order to avoid SQL injection vulnerabilities.]]>

The following server-side pseudo-code is used to authenticate users to the web application.
 # Define POST variables uname = request.POST['username'] passwd = request.POST['password']  # SQL query vulnerable to SQLi sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"  # Execute the SQL statement database.execute(sql)
The above script is a simple example of authenticating a user with a username and a password against a database with a table named users, and a username and password column.

The above script is vulnerable to SQL injection because an attacker could submit malicious input in such a way that would alter the SQL statement being executed by the database server.

A simple example of an SQL injection payload could be something as simple as setting the password field to password' OR 1=1.

This would result in the following SQL query being run against the database server.
 SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query further.
 -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite ' OR '1'='1' -- ' OR '1'='1' /* -- MySQL ' OR '1'='1' # -- Access (using null characters) ' OR '1'='1' %00 ' OR '1'='1' %16
Once the query executes, the result is returned to the application to be processed, resulting in an authentication bypass. In the event of authentication bypass being possible, the application will most likely log the attacker in with the first account from the query result — the first account in a database is usually of an administrative user.

What's the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run commands on the operating system from an SQL statement.

Keeping the above in mind, when considering the following, it's easier to understand how lucrative a successful SQL injection attack can be for an attacker.

  • An attacker can use SQL injection to bypass authentication or even impersonate specific users.
  • One of SQL's primary functions is to select data based on a query and output the result of that query. An SQL injection vulnerability could allow the complete disclosure of data residing on a database server.
  • Since web applications use SQL to alter data within a database, an attacker could use SQL injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
  • SQL is used to delete records from a database. An attacker could use an SQL injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application's availability until the database is restored.
  • Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL injection as the initial vector in an attack of an internal network that sits behind a firewall.

Preventing SQL injection using parameterized queries
SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both the programming languages, as well as the RDBMSs themselves have evolved to provide web application developers with a way to safely query the database — parameterized SQL queries.

Parameterized queries are simple to write and understand while forcing a developer to define the entire SQL statement before hand, using placeholders for the actual variables within that statement. A developer would then pass in each parameter to the query after the SQL statement is defined, allowing the database to be able to distinguish between the SQL command and data inputted by a user. If SQL commands are inputted by an attacker, the parameterized query would treat the input as a string as opposed to an SQL command.

Application developers should avoid sanitizing their input by means of escaping or removing special characters (several encoding tricks an attacker could leverage to bypass such protections) and stick to using parameterized queries in order to avoid SQL injection vulnerabilities.]]>

The following server-side pseudo-code is used to authenticate users to the web application.
 # Define POST variables uname = request.POST['username'] passwd = request.POST['password']  # SQL query vulnerable to SQLi sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"  # Execute the SQL statement database.execute(sql)
The above script is a simple example of authenticating a user with a username and a password against a database with a table named users, and a username and password column.

The above script is vulnerable to SQL injection because an attacker could submit malicious input in such a way that would alter the SQL statement being executed by the database server.

A simple example of an SQL injection payload could be something as simple as setting the password field to password' OR 1=1.

This would result in the following SQL query being run against the database server.
 SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query further.
 -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite ' OR '1'='1' -- ' OR '1'='1' /* -- MySQL ' OR '1'='1' # -- Access (using null characters) ' OR '1'='1' %00 ' OR '1'='1' %16
Once the query executes, the result is returned to the application to be processed, resulting in an authentication bypass. In the event of authentication bypass being possible, the application will most likely log the attacker in with the first account from the query result — the first account in a database is usually of an administrative user.

What's the worst an attacker can do with SQL?
SQL is a programming language designed for managing data stored in an RDBMS, therefore SQL can be used to access, modify and delete data. Furthermore, in specific cases, an RDBMS could also run commands on the operating system from an SQL statement.

Keeping the above in mind, when considering the following, it's easier to understand how lucrative a successful SQL injection attack can be for an attacker.

  • An attacker can use SQL injection to bypass authentication or even impersonate specific users.
  • One of SQL's primary functions is to select data based on a query and output the result of that query. An SQL injection vulnerability could allow the complete disclosure of data residing on a database server.
  • Since web applications use SQL to alter data within a database, an attacker could use SQL injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
  • SQL is used to delete records from a database. An attacker could use an SQL injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application's availability until the database is restored.
  • Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL injection as the initial vector in an attack of an internal network that sits behind a firewall.

Preventing SQL injection using parameterized queries
SQL injection is one of the most widely spread and most damaging web application vulnerabilities. Fortunately, both the programming languages, as well as the RDBMSs themselves have evolved to provide web application developers with a way to safely query the database — parameterized SQL queries.

Parameterized queries are simple to write and understand while forcing a developer to define the entire SQL statement before hand, using placeholders for the actual variables within that statement. A developer would then pass in each parameter to the query after the SQL statement is defined, allowing the database to be able to distinguish between the SQL command and data inputted by a user. If SQL commands are inputted by an attacker, the parameterized query would treat the input as a string as opposed to an SQL command.

Application developers should avoid sanitizing their input by means of escaping or removing special characters (several encoding tricks an attacker could leverage to bypass such protections) and stick to using parameterized queries in order to avoid SQL injection vulnerabilities.]]>

XPath Injection is an attack technique used to exploit web sites that construct XPath queries from user-supplied input.]]>
This alert requires manual confirmation
Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]> some of the information an attacker may be able to obtain from application error disclosure.
  • Internal IP addresses
  • Secrets (passwords, keys, tokens...)
  • Operating system distributions
  • Software version numbers
  • Missing security patches
  • Application stack traces
  • SQL statements
  • Location of sensitive files (backups, temporary files...)
  • Location of sensitive resources (databases, caches, code repositories...)
      • ]]>
      This alert requires manual confirmation
      Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

      Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>       some of the information an attacker may be able to obtain from application error disclosure.
      • Internal IP addresses
      • Secrets (passwords, keys, tokens...)
      • Operating system distributions
      • Software version numbers
      • Missing security patches
      • Application stack traces
      • SQL statements
      • Location of sensitive files (backups, temporary files...)
      • Location of sensitive resources (databases, caches, code repositories...)
          • ]]>
          This alert requires manual confirmation
          Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

          Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>           some of the information an attacker may be able to obtain from application error disclosure.
          • Internal IP addresses
          • Secrets (passwords, keys, tokens...)
          • Operating system distributions
          • Software version numbers
          • Missing security patches
          • Application stack traces
          • SQL statements
          • Location of sensitive files (backups, temporary files...)
          • Location of sensitive resources (databases, caches, code repositories...)
              • ]]>
              This alert requires manual confirmation
              Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

              Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>               some of the information an attacker may be able to obtain from application error disclosure.
              • Internal IP addresses
              • Secrets (passwords, keys, tokens...)
              • Operating system distributions
              • Software version numbers
              • Missing security patches
              • Application stack traces
              • SQL statements
              • Location of sensitive files (backups, temporary files...)
              • Location of sensitive resources (databases, caches, code repositories...)
                  • ]]>
                  This alert requires manual confirmation
                  Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                  Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                   some of the information an attacker may be able to obtain from application error disclosure.
                  • Internal IP addresses
                  • Secrets (passwords, keys, tokens...)
                  • Operating system distributions
                  • Software version numbers
                  • Missing security patches
                  • Application stack traces
                  • SQL statements
                  • Location of sensitive files (backups, temporary files...)
                  • Location of sensitive resources (databases, caches, code repositories...)
                      • ]]>
                      This alert requires manual confirmation
                      Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                      Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                       some of the information an attacker may be able to obtain from application error disclosure.
                      • Internal IP addresses
                      • Secrets (passwords, keys, tokens...)
                      • Operating system distributions
                      • Software version numbers
                      • Missing security patches
                      • Application stack traces
                      • SQL statements
                      • Location of sensitive files (backups, temporary files...)
                      • Location of sensitive resources (databases, caches, code repositories...)
                          • ]]>
                          This alert requires manual confirmation
                          Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                          Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                           some of the information an attacker may be able to obtain from application error disclosure.
                          • Internal IP addresses
                          • Secrets (passwords, keys, tokens...)
                          • Operating system distributions
                          • Software version numbers
                          • Missing security patches
                          • Application stack traces
                          • SQL statements
                          • Location of sensitive files (backups, temporary files...)
                          • Location of sensitive resources (databases, caches, code repositories...)
                              • ]]>
                              This alert requires manual confirmation
                              Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                              Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                               some of the information an attacker may be able to obtain from application error disclosure.
                              • Internal IP addresses
                              • Secrets (passwords, keys, tokens...)
                              • Operating system distributions
                              • Software version numbers
                              • Missing security patches
                              • Application stack traces
                              • SQL statements
                              • Location of sensitive files (backups, temporary files...)
                              • Location of sensitive resources (databases, caches, code repositories...)
                                  • ]]>
                                  This alert requires manual confirmation
                                  Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                  Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                   some of the information an attacker may be able to obtain from application error disclosure.
                                  • Internal IP addresses
                                  • Secrets (passwords, keys, tokens...)
                                  • Operating system distributions
                                  • Software version numbers
                                  • Missing security patches
                                  • Application stack traces
                                  • SQL statements
                                  • Location of sensitive files (backups, temporary files...)
                                  • Location of sensitive resources (databases, caches, code repositories...)
                                      • ]]>
                                      This alert requires manual confirmation
                                      Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                      Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                       some of the information an attacker may be able to obtain from application error disclosure.
                                      • Internal IP addresses
                                      • Secrets (passwords, keys, tokens...)
                                      • Operating system distributions
                                      • Software version numbers
                                      • Missing security patches
                                      • Application stack traces
                                      • SQL statements
                                      • Location of sensitive files (backups, temporary files...)
                                      • Location of sensitive resources (databases, caches, code repositories...)
                                          • ]]>
                                          This alert requires manual confirmation
                                          Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                          Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                           some of the information an attacker may be able to obtain from application error disclosure.
                                          • Internal IP addresses
                                          • Secrets (passwords, keys, tokens...)
                                          • Operating system distributions
                                          • Software version numbers
                                          • Missing security patches
                                          • Application stack traces
                                          • SQL statements
                                          • Location of sensitive files (backups, temporary files...)
                                          • Location of sensitive resources (databases, caches, code repositories...)
                                              • ]]>
                                              This alert requires manual confirmation
                                              Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                              Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                               some of the information an attacker may be able to obtain from application error disclosure.
                                              • Internal IP addresses
                                              • Secrets (passwords, keys, tokens...)
                                              • Operating system distributions
                                              • Software version numbers
                                              • Missing security patches
                                              • Application stack traces
                                              • SQL statements
                                              • Location of sensitive files (backups, temporary files...)
                                              • Location of sensitive resources (databases, caches, code repositories...)
                                                  • ]]>
                                                  This alert requires manual confirmation
                                                  Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                  Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                   some of the information an attacker may be able to obtain from application error disclosure.
                                                  • Internal IP addresses
                                                  • Secrets (passwords, keys, tokens...)
                                                  • Operating system distributions
                                                  • Software version numbers
                                                  • Missing security patches
                                                  • Application stack traces
                                                  • SQL statements
                                                  • Location of sensitive files (backups, temporary files...)
                                                  • Location of sensitive resources (databases, caches, code repositories...)
                                                      • ]]>
                                                      This alert requires manual confirmation
                                                      Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                      Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                       some of the information an attacker may be able to obtain from application error disclosure.
                                                      • Internal IP addresses
                                                      • Secrets (passwords, keys, tokens...)
                                                      • Operating system distributions
                                                      • Software version numbers
                                                      • Missing security patches
                                                      • Application stack traces
                                                      • SQL statements
                                                      • Location of sensitive files (backups, temporary files...)
                                                      • Location of sensitive resources (databases, caches, code repositories...)
                                                          • ]]>
                                                          This alert requires manual confirmation
                                                          Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                          Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                           some of the information an attacker may be able to obtain from application error disclosure.
                                                          • Internal IP addresses
                                                          • Secrets (passwords, keys, tokens...)
                                                          • Operating system distributions
                                                          • Software version numbers
                                                          • Missing security patches
                                                          • Application stack traces
                                                          • SQL statements
                                                          • Location of sensitive files (backups, temporary files...)
                                                          • Location of sensitive resources (databases, caches, code repositories...)
                                                              • ]]>
                                                              This alert requires manual confirmation
                                                              Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                              Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                               some of the information an attacker may be able to obtain from application error disclosure.
                                                              • Internal IP addresses
                                                              • Secrets (passwords, keys, tokens...)
                                                              • Operating system distributions
                                                              • Software version numbers
                                                              • Missing security patches
                                                              • Application stack traces
                                                              • SQL statements
                                                              • Location of sensitive files (backups, temporary files...)
                                                              • Location of sensitive resources (databases, caches, code repositories...)
                                                                  • ]]>
                                                                  This alert requires manual confirmation
                                                                  Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                                  Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                                   some of the information an attacker may be able to obtain from application error disclosure.
                                                                  • Internal IP addresses
                                                                  • Secrets (passwords, keys, tokens...)
                                                                  • Operating system distributions
                                                                  • Software version numbers
                                                                  • Missing security patches
                                                                  • Application stack traces
                                                                  • SQL statements
                                                                  • Location of sensitive files (backups, temporary files...)
                                                                  • Location of sensitive resources (databases, caches, code repositories...)
                                                                      • ]]>
                                                                      This alert requires manual confirmation
                                                                      Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                                      Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                                       some of the information an attacker may be able to obtain from application error disclosure.
                                                                      • Internal IP addresses
                                                                      • Secrets (passwords, keys, tokens...)
                                                                      • Operating system distributions
                                                                      • Software version numbers
                                                                      • Missing security patches
                                                                      • Application stack traces
                                                                      • SQL statements
                                                                      • Location of sensitive files (backups, temporary files...)
                                                                      • Location of sensitive resources (databases, caches, code repositories...)
                                                                          • ]]>
                                                                          This alert requires manual confirmation
                                                                          Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                                          Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                                           some of the information an attacker may be able to obtain from application error disclosure.
                                                                          • Internal IP addresses
                                                                          • Secrets (passwords, keys, tokens...)
                                                                          • Operating system distributions
                                                                          • Software version numbers
                                                                          • Missing security patches
                                                                          • Application stack traces
                                                                          • SQL statements
                                                                          • Location of sensitive files (backups, temporary files...)
                                                                          • Location of sensitive resources (databases, caches, code repositories...)
                                                                              • ]]>
                                                                              This alert requires manual confirmation
                                                                              Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                                              Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                                               some of the information an attacker may be able to obtain from application error disclosure.
                                                                              • Internal IP addresses
                                                                              • Secrets (passwords, keys, tokens...)
                                                                              • Operating system distributions
                                                                              • Software version numbers
                                                                              • Missing security patches
                                                                              • Application stack traces
                                                                              • SQL statements
                                                                              • Location of sensitive files (backups, temporary files...)
                                                                              • Location of sensitive resources (databases, caches, code repositories...)
                                                                                  • ]]>
                                                                                  This alert requires manual confirmation
                                                                                  Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                                                  Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                                                   some of the information an attacker may be able to obtain from application error disclosure.
                                                                                  • Internal IP addresses
                                                                                  • Secrets (passwords, keys, tokens...)
                                                                                  • Operating system distributions
                                                                                  • Software version numbers
                                                                                  • Missing security patches
                                                                                  • Application stack traces
                                                                                  • SQL statements
                                                                                  • Location of sensitive files (backups, temporary files...)
                                                                                  • Location of sensitive resources (databases, caches, code repositories...)
                                                                                      • ]]>
                                                                                      This alert requires manual confirmation
                                                                                      Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                                                      Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                                                       some of the information an attacker may be able to obtain from application error disclosure.
                                                                                      • Internal IP addresses
                                                                                      • Secrets (passwords, keys, tokens...)
                                                                                      • Operating system distributions
                                                                                      • Software version numbers
                                                                                      • Missing security patches
                                                                                      • Application stack traces
                                                                                      • SQL statements
                                                                                      • Location of sensitive files (backups, temporary files...)
                                                                                      • Location of sensitive resources (databases, caches, code repositories...)
                                                                                          • ]]>

                                                                                          HTTP headers have the structure "Key: Value", where each line is separated by the CRLF combination. If the user input is injected into the value section without properly escaping/removing CRLF characters it is possible to alter the HTTP headers structure.
                                                                                          HTTP Response Splitting is a new application attack technique which enables various new attacks such as web cache poisoning, cross user defacement, hijacking pages with sensitive user information and cross-site scripting (XSS). The attacker sends a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response.]]>

                                                                                          HTTP headers have the structure "Key: Value", where each line is separated by the CRLF combination. If the user input is injected into the value section without properly escaping/removing CRLF characters it is possible to alter the HTTP headers structure.
                                                                                          HTTP Response Splitting is a new application attack technique which enables various new attacks such as web cache poisoning, cross user defacement, hijacking pages with sensitive user information and cross-site scripting (XSS). The attacker sends a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response.]]>
                                                                                          How to disable directory listings
                                                                                          • The easiest way to disable directory listing is to create an index file. The name of the index file depends on the web server configuration. On Apache is called index.htm, index.html. On IIS is named default.asp, default.aspx, default.htm.
                                                                                          • On IIS directory listings are disabled by default.
                                                                                          • For Apache you need to edit the Apache configuration file (usually named httpd.conf) or create an .htaccess file. In the configuration file you will have the definition of the directory. Something like 
                                                                                            <Directory  /directoryname/subdirectory> Options Indexes FollowSymLinks ... </Directory>
                                                                                            To disable directory listing for that directory you need to remove the 'Indexes' option.
                                                                                          ]]>
                                                                                          How to disable directory listings
                                                                                          • The easiest way to disable directory listing is to create an index file. The name of the index file depends on the web server configuration. On Apache is called index.htm, index.html. On IIS is named default.asp, default.aspx, default.htm.
                                                                                          • On IIS directory listings are disabled by default.
                                                                                          • For Apache you need to edit the Apache configuration file (usually named httpd.conf) or create an .htaccess file. In the configuration file you will have the definition of the directory. Something like 
                                                                                            <Directory  /directoryname/subdirectory> Options Indexes FollowSymLinks ... </Directory>
                                                                                            To disable directory listing for that directory you need to remove the 'Indexes' option.
                                                                                          ]]>
                                                                                          This alert requires manual confirmation
                                                                                          Application error or warning messages may expose sensitive information about an application's internal workings to an attacker.

                                                                                          Acunetix found an error or warning message that may disclose sensitive information. The message may also contain the location of the file that produced an unhandled exception. Consult the 'Attack details' section for more information about the affected page.]]>                                                                                           some of the information an attacker may be able to obtain from application error disclosure.
                                                                                          • Internal IP addresses
                                                                                          • Secrets (passwords, keys, tokens...)
                                                                                          • Operating system distributions
                                                                                          • Software version numbers
                                                                                          • Missing security patches
                                                                                          • Application stack traces
                                                                                          • SQL statements
                                                                                          • Location of sensitive files (backups, temporary files...)
                                                                                          • Location of sensitive resources (databases, caches, code repositories...)
                                                                                              • ]]>

                                                                                              CSRF is a type of 'confused deputy' attack which leverages the authentication and authorization of the victim when the forged request is being sent to the web server. Therefore, if a CSRF vulnerability could affect highly privileged users such as administrators full application compromise may be possible.]]>                                                                                               This alert requires manual confirmation
                                                                                              Cross-Site Request Forgery (CSRF, or XSRF) is a vulnerability wherein an attacker tricks a victim into making a request the victim did not intend to make. Therefore, with CSRF, an attacker abuses the trust a web application has with a victim's browser.

                                                                                              Acunetix found an HTML form with no apparent anti-CSRF protection implemented. Consult the 'Attack details' section for more information about the affected HTML form.]]>
                                                                                              Upon sending an HTTP request (legitimate or otherwise), the victim's browser will include the Cookie header. Cookies are typically used to store a user's session identifier in order to prevent the user from authenticating for each request, which would obviously be impractical.

                                                                                              To such an extent, if the victim's authentication session is stored in a Cookie, and is still valid (a browser window/tab does not necessarily need to be open), if the application is vulnerable to CSRF, an attacker can leverage CSRF to launch any desired requests against the website, without the website being able to distinguish whether the requests are legitimate or not.

                                                                                              CSRF in GET requests
                                                                                              The following is a simple example of how CSRF can be abused in GET requests through the use of the <img> tag.
                                                                                               <img src="http://example.com/changePassword/?newPassword=attackerPassword">

                                                                                              The above is a CSRF attack using an HTTP GET request. If a victim visits a web page controlled by an attacker with the following payload, the browser will send a request containing the Cookie to the attacker crafted URL.

                                                                                              CSRF in GET requests
                                                                                              GET requests, however are not the only HTTP method an attacker can abuse. POST requests are equally susceptible to CSRF, however, an attacker will need to make use of a little bit of JavaScript to submit the POST request.

                                                                                              The following is a simple example of how CSRF can be abused POST requests through the use of an <iframe> tag. This code would be loaded in an iFrame which is made invisible to the victim.

                                                                                              iFrame 
                                                                                               <iframe src="http://attacker.com/csrfAttack" style="width:0;height:0;border:0;border:none;"></iframe>
                                                                                              iFrame Contents 
                                                                                               <body onload="document.getElementById('csrf').submit()">   <form id="csrf" action="http://example.com/changePassword" method="POST">     <input name="newPassword" value="attackerPassword" />   </form> </body>
                                                                                              ]]>
                                                                                              The recommended and the most widely used technique for preventing CSRF attacks is know as an anti-CSRF token, also sometimes referred to as a synchronizer token. The characteristics of a well designed anti-CSRF system involve the following attributes.

                                                                                              • The anti-CSRF token should be unique for each user session
                                                                                              • The session should automatically expire after a suitable amount of time
                                                                                              • The anti-CSRF token should be a cryptographically random value of significant length
                                                                                              • The anti-CSRF token should be cryptographically secure, that is, generated by a strong Pseudo-Random Number Generator (PRNG) algorithm
                                                                                              • The anti-CSRF token is added as a hidden field for forms, or within URLs (only necessary if GET requests cause state changes, that is, GET requests are not idempotent)
                                                                                              • The server should reject the requested action if the anti-CSRF token fails validation

                                                                                              When a user submits a form or makes some other authenticated request that requires a Cookie, the anti-CSRF token should be included in the request. Then, the web application will then verify the existence and correctness of this token before processing the request. If the token is missing or incorrect, the request can be rejected.]]>
                                                                                              Web.Config and add the following line under the <system.web> element: 
                                                                                              <machineKey validation="AES"/>
                                                                                              ]]>
                                                                                              Web.Config and add the following line under the <system.web> element: 
                                                                                              <machineKey validation="AES"/>
                                                                                              ]]>
                                                                                              Web.Config and add the following line under the <system.web> element: 
                                                                                              <machineKey validation="AES"/>
                                                                                              ]]>
                                                                                              X-AspNet-Version. The value of this header is used by Visual Studio to determine which version of ASP.NET is in use. It is not necessary for production sites and should be disabled.]]> <System.Web> <httpRuntime enableVersionHeader="false" /> </System.Web> ]]>

                                                                                              The server didn't return an X-Frame-Options header which means that this website could be at risk of a clickjacking attack. The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page inside a frame or iframe. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Manual confirmation is required for this alert.
                                                                                              Gareth Heyes introduced a technique to take advantage of CSS imports with relative URLs by overwriting their target file. This technique can be used by an attacker to trick browsers into importing HTML pages as CSS stylesheets. If the attacker can control a part of the imported HTML pages he can abuse this issue to inject arbitrary CSS rules. ]]>
                                                                                              Server. The value of this header includes the version of Microsoft IIS server.]]>
                                                                                              To disable auto-complete, you may use a code similar to: 
                                                                                              <INPUT TYPE="password" AUTOCOMPLETE="off">
                                                                                              ]]>