Cyber Strategy
Cyber Secure
Cyber Operations
Cyber Response
Cyber ResilienceInjection flaws
As the use of web applications for critical services has increased, the number and sophistication of attacks against web application has grown as well. Most of the security breaches seem to have one thing in common- they are attacks that exploited some weakness in the software layer. Web application vulnerabilities are typically the result of a lack of input/output sanitization, which are often exploited to either manipulate source code or gain unauthorized access.
Hackers have been exposing and exploiting vulnerabilities for decades and seem to be increasing their attacks. Traditional perimeter defenses are increasingly unable to stop software attacks as more and more hackers focus on the software layer and shy away from attacks against the system and networking layer.
A coordinated effort by the software development community to produce more robust and reliable applications will prevent attackers and allow users and stakeholders to feel confident that they are protected from exploitation.
Injection flaws
As the use of web applications for critical services has increased, the number and sophistication of attacks against web application has grown as well. Most of the security breaches seem to have one thing in common- they are attacks that exploited some weakness in the software layer. Web application vulnerabilities are typically the result of a lack of input/output sanitization, which are often exploited to either manipulate source code or gain unauthorized access.
Hackers have been exposing and exploiting vulnerabilities for decades and seem to be increasing their attacks. Traditional perimeter defenses are increasingly unable to stop software attacks as more and more hackers focus on the software layer and shy away from attacks against the system and networking layer.
A coordinated effort by the software development community to produce more robust and reliable applications will prevent attackers and allow users and stakeholders to feel confident that they are protected from exploitation.
Injection Flaws Types
Injection flaws occur when the user supplied data is not validated before being processed by an interpreter. The attacker supplies data that is accepted as is and interpreted as a command or part of a command, thus allowing the attacker to execute commands using any injection vector.
Injection flaws are easily discoverable using code review and scanners, including fuzzing scans, can be employed to detect them There are several different types of injection attacks. The most common ones include:
- SQL injection
- OS Command injection
- LDAP injection and
- XML injection
Injection Flaws Types
Injection flaws occur when the user supplied data is not validated before being processed by an interpreter. The attacker supplies data that is accepted as is and interpreted as a command or part of a command, thus allowing the attacker to execute commands using any injection vector.
Injection flaws are easily discoverable using code review and scanners, including fuzzing scans, can be employed to detect them There are several different types of injection attacks. The most common ones include:
- SQL injection
- OS Command injection
- LDAP injection and
- XML injection
SQL Injection
The SQL injection vulnerability is one of the most dangerous issues for data confidentiality and integrity in web applications and has been listed in the OWASP Top 10 list of the most common and widely exploited vulnerabilities since its inception.It is the most well known form of injection attacks as the databases that store business data are becoming the prime target for attackers. In SQL injection, attackers exploit the way in which database queries are constructed. Let’s consider an example of a vulnerable code implementation in which the query command text (dtsSQLQuery) is dynamically built using the data that is supplied from text input fields (txtUserID and txtPassword) from the web form.
string dtsSQLQuery = ” SELECT * FROM USERS WHERE user_id = ‘ ” + txtUserID.Text + ” ‘ AND user_password = ‘ ” + txtPassword.Text + ” ‘
If the attacker supplies ‘ OR 1=1 — as the txtUserID value, then the SQL Query command text that is generated is as follows:
string sSQLQuery = “SELECT * FROM USERS WHERE user_id = ‘ “+ ‘ OR 1=1 — + ” ‘ AND user_password = ‘ ” + txtPassword.Text + ” ‘
This results in SQL syntax as shown below, that the interpreter will evaluate and execute as a valid SQL command. Everything after the — in T-SQL is ignored.
SELECT * FROM USERS WHERE user_id = ‘ “+ ‘ OR 1=1 —
SQL Injection
The SQL injection vulnerability is one of the most dangerous issues for data confidentiality and integrity in web applications and has been listed in the OWASP Top 10 list of the most common and widely exploited vulnerabilities since its inception.It is the most well known form of injection attacks as the databases that store business data are becoming the prime target for attackers. In SQL injection, attackers exploit the way in which database queries are constructed. Let’s consider an example of a vulnerable code implementation in which the query command text (dtsSQLQuery) is dynamically built using the data that is supplied from text input fields (txtUserID and txtPassword) from the web form.
string dtsSQLQuery = ” SELECT * FROM USERS WHERE user_id = ‘ ” + txtUserID.Text + ” ‘ AND user_password = ‘ ” + txtPassword.Text + ” ‘
If the attacker supplies ‘ OR 1=1 — as the txtUserID value, then the SQL Query command text that is generated is as follows:
string sSQLQuery = “SELECT * FROM USERS WHERE user_id = ‘ “+ ‘ OR 1=1 — + ” ‘ AND user_password = ‘ ” + txtPassword.Text + ” ‘
This results in SQL syntax as shown below, that the interpreter will evaluate and execute as a valid SQL command. Everything after the — in T-SQL is ignored.
SELECT * FROM USERS WHERE user_id = ‘ “+ ‘ OR 1=1 —
SQL Injection Mitigation Strategies
Secure Coding & SDLC
Security driven programming practices will always be the best defense against SQL Injection attacks. Ensuring developers are aware the the risks, tools, and the techniques which can mitigate SQL vulnerabilities is your first and best line of defense.Developing security minded education, planning, testing, and review practices are just a few components within an SDLC that will help prevent SQL Injection vulnerabilities from making their way into your application
Input Validation & Sanitation
Client side input sanitization and validation should only be considered a convenience for the end user, improving their user experience.Just because the browser’s user interface doesn’t allow the user to manipulate an input, it doesn’t mean that it can’t be tampered with. Server side sanitization and input validation ensures data supplied by the user does not contain characters like single or double quotes that could modify an SQL query and return data not originally intended in the application’s design. For instance, in PHP, you can use the mysql_real_escape_string() to escape characters that might change the nature of the SQL command.
Use Stored Procedures
When possible, permit applications to interact with the database only through stored procedures. That way, the database account used by the application requires only the permissions necessary to execute the stored procedure, without needing permissions to access the underlying tables
Prepared Statements (Parameterized Queries) –
Parameterized queries force developers to define all the SQL code, then pass in each parameter to the query, which allows the database to distinguish between code and data, regardless of what input is supplied.
Update and patch
Vulnerabilities in applications and databases that hackers can exploit using SQL injection are regularly discovered, so it’s vital to apply patches and updates as soon as practical
Web Application Firewall (WAF)
Consider a web application firewall (WAF) – either software or appliance-based – to help filter out malicious data.
Use Appropriate Privileges
Don’t connect to your database using an account with admin-level privileges unless there is some compelling reason to do so. Using a limited access account is far safer, and can limit what a hacker is able to do.
Avoid Disclosing Error Information
Use structured exception handling to catch errors and prevent them from propagating back to the client. Log detailed error information locally, but return limited error details to the client.
The good news here is that these attacks are very simple to prevent or avoid. The Open Web Application Security Project has a SQL Injection Prevention Cheat Sheet, which outlined primary and additional defenses. Have you experienced an Injection hack at your organization? How did your organization combat the attack? Let us know.
SQL Injection Mitigation Strategies
Secure Coding & SDLC
Security driven programming practices will always be the best defense against SQL Injection attacks. Ensuring developers are aware the the risks, tools, and the techniques which can mitigate SQL vulnerabilities is your first and best line of defense.Developing security minded education, planning, testing, and review practices are just a few components within an SDLC that will help prevent SQL Injection vulnerabilities from making their way into your application
Input Validation & Sanitation
Client side input sanitization and validation should only be considered a convenience for the end user, improving their user experience.Just because the browser’s user interface doesn’t allow the user to manipulate an input, it doesn’t mean that it can’t be tampered with. Server side sanitization and input validation ensures data supplied by the user does not contain characters like single or double quotes that could modify an SQL query and return data not originally intended in the application’s design. For instance, in PHP, you can use the mysql_real_escape_string() to escape characters that might change the nature of the SQL command.
Use Stored Procedures
When possible, permit applications to interact with the database only through stored procedures. That way, the database account used by the application requires only the permissions necessary to execute the stored procedure, without needing permissions to access the underlying tables
Prepared Statements (Parameterized Queries) –
Parameterized queries force developers to define all the SQL code, then pass in each parameter to the query, which allows the database to distinguish between code and data, regardless of what input is supplied.
Update and patch
Vulnerabilities in applications and databases that hackers can exploit using SQL injection are regularly discovered, so it’s vital to apply patches and updates as soon as practical
Web Application Firewall (WAF)
Consider a web application firewall (WAF) – either software or appliance-based – to help filter out malicious data.
Use Appropriate Privileges
Don’t connect to your database using an account with admin-level privileges unless there is some compelling reason to do so. Using a limited access account is far safer, and can limit what a hacker is able to do.
Avoid Disclosing Error Information
Use structured exception handling to catch errors and prevent them from propagating back to the client. Log detailed error information locally, but return limited error details to the client.
The good news here is that these attacks are very simple to prevent or avoid. The Open Web Application Security Project has a SQL Injection Prevention Cheat Sheet, which outlined primary and additional defenses. Have you experienced an Injection hack at your organization? How did your organization combat the attack? Let us know.
OS Command Injection
Sometimes web applications need to communicate with the underlying operating system. This can either be to run system commands or to start applications written in another programming language such as shell, or execute a python script.
OS Command Injection Occurs when command string is generated dynamically using input supplied by the user.When the software allows the execution of Operation System (OS) level commands using the supplied user input without sanitization or validation, it is said to be susceptible to OS Command injection
OS Command Injection
Sometimes web applications need to communicate with the underlying operating system. This can either be to run system commands or to start applications written in another programming language such as shell, or execute a python script.
OS Command Injection Occurs when command string is generated dynamically using input supplied by the user.When the software allows the execution of Operation System (OS) level commands using the supplied user input without sanitization or validation, it is said to be susceptible to OS Command injection
The two main types of OS Command injection are as follows
- The software accepts arguments from the user to execute a single fixed program command. In such cases, the injection is contained only to the command that is allowed to execute and the attacker can change the input but not the command itself. Here, the programming error is that the programmer assumes that the input supplied by users to be part of the arguments in the command to be executed will be trustworthy as intended, and not malicious
- The software accepts arguments from the user which specifies what program command they would like the system to execute. This is a lot more serious than the previous case, because now the attacker can chain multiple commands and do some serious damage to the system by executing their own commands that the system supports. Here, the programming error is that the programmer assumes that the command itself will not be accessible to untrusted users.
An example of an OS Command injection that an attacker supplies as the value of a QueryString parameter to execute the bin/ls command to list all files in the ‘bin’ directory is given below:
http://www.mycompany.com/sensitive/cgi-bin/userData.pl?doc=%20%3B%20/bin/ls%20-l
%20 decodes to a space and %3B decodes to a ; and the command that is executed will be /bin/ls -l listing the contents of the program’s working directory.
The following PHP code snippet is vulnerable to a command injection attack(web app):
$file=$_GET[‘filename’];
system(“rm $file”);
system(“rm $file”);
The following request and response is an example of a successful attack:
Request
http://mywesite.com/delete.php?filename=bob.txt;id
Response
Please specify the name of the file to delete
uid=33(www-data) gid=33(www-data) groups=33(www-data)
OS Command Injection Prevention
- Avoid system calls where possible
- Avoid user input of any kind inside them unless it is absolutely necessary and deactivate that function in your language's configuration file if you don't need it.
- Build a whitelist of possible inputs and check its format
The two main types of OS Command injection are as follows
- The software accepts arguments from the user to execute a single fixed program command. In such cases, the injection is contained only to the command that is allowed to execute and the attacker can change the input but not the command itself. Here, the programming error is that the programmer assumes that the input supplied by users to be part of the arguments in the command to be executed will be trustworthy as intended, and not malicious
- The software accepts arguments from the user which specifies what program command they would like the system to execute. This is a lot more serious than the previous case, because now the attacker can chain multiple commands and do some serious damage to the system by executing their own commands that the system supports. Here, the programming error is that the programmer assumes that the command itself will not be accessible to untrusted users.
An example of an OS Command injection that an attacker supplies as the value of a QueryString parameter to execute the bin/ls command to list all files in the ‘bin’ directory is given below:
http://www.mycompany.com/sensitive/cgi-bin/userData.pl?doc=%20%3B%20/bin/ls%20-l
%20 decodes to a space and %3B decodes to a ; and the command that is executed will be /bin/ls -l listing the contents of the program’s working directory.
The following PHP code snippet is vulnerable to a command injection attack(web app):
$file=$_GET[‘filename’];
system(“rm $file”);
system(“rm $file”);
The following request and response is an example of a successful attack:
Request
http://mywesite.com/delete.php?filename=bob.txt;id
Response
Please specify the name of the file to delete
uid=33(www-data) gid=33(www-data) groups=33(www-data)
OS Command Injection Prevention
- Avoid system calls where possible
- Avoid user input of any kind inside them unless it is absolutely necessary and deactivate that function in your language's configuration file if you don't need it.
- Build a whitelist of possible inputs and check its format
LDAP Injection
LDAP Injection is an attack technique used to exploit web sites that construct LDAP statements from user-supplied input. Lightweight Directory Access Protocol (LDAP) is an open-standard protocol for both querying and manipulating X.500 directory services. The LDAP protocol runs over Internet transport protocols, such as TCP. Web applications may use user-supplied input to create custom LDAP statements for dynamic web page requests.
LDAP injection works on the same principle as SQL injection or OS command injection. Unsanitized and unvalidated input is used to construct or modify syntax, contents and commands that are executed as an LDAP query. Compromise can lead to the disclosure of sensitive and private information as well as manipulation of content within the LDAP tree (hierarchical) structure. Say you have the ldap query (_sldapQuery) built dynamically using the user supplied input (userName) without any validation as shown in the example below.
If the attacker supplies the wildcard ‘*’, information about all users listed in the directory will be disclosed. If the user supplies the value such as “”ahmed)(|password=*))”, the execution of the LDAP query will yield the password for the user ‘ahmed’.
String _sldapQuery = ’’ (cn=’’ + $userName + ’’) ’ ’;
How to prevent LDAP injection attacks?
- Safe LDAP Configuration – This involves the safeguarding of sensitive information and data in the LDAP directory, especially while dealing with permissions on user objects. This is all the more important when the directory is used by the web/mobile application for a single logging-on process.
- Advanced input validation – All user-end input must be sanitized thoroughly. It should be free of suspicious characters and strings that can be malicious.
-
Output regulation – Limits and restrictions should also be placed on the amount of data/information returned by the LDAP servers to the client
LDAP Injection
LDAP Injection is an attack technique used to exploit web sites that construct LDAP statements from user-supplied input. Lightweight Directory Access Protocol (LDAP) is an open-standard protocol for both querying and manipulating X.500 directory services. The LDAP protocol runs over Internet transport protocols, such as TCP. Web applications may use user-supplied input to create custom LDAP statements for dynamic web page requests.
LDAP injection works on the same principle as SQL injection or OS command injection. Unsanitized and unvalidated input is used to construct or modify syntax, contents and commands that are executed as an LDAP query. Compromise can lead to the disclosure of sensitive and private information as well as manipulation of content within the LDAP tree (hierarchical) structure. Say you have the ldap query (_sldapQuery) built dynamically using the user supplied input (userName) without any validation as shown in the example below.
If the attacker supplies the wildcard ‘*’, information about all users listed in the directory will be disclosed. If the user supplies the value such as “”ahmed)(|password=*))”, the execution of the LDAP query will yield the password for the user ‘ahmed’.
String _sldapQuery = ’’ (cn=’’ + $userName + ’’) ’ ’;
If the attacker supplies the wildcard ‘*’, information about all users listed in the directory will be disclosed. If the user supplies the value such as “”ahmed)(|password=*))”, the execution of the LDAP query will yield the password for the user ‘ahmed’.
How to prevent LDAP injection attacks?
- Safe LDAP Configuration – This involves the safeguarding of sensitive information and data in the LDAP directory, especially while dealing with permissions on user objects. This is all the more important when the directory is used by the web/mobile application for a single logging-on process.
- Advanced input validation – All user-end input must be sanitized thoroughly. It should be free of suspicious characters and strings that can be malicious.
- Output regulation – Limits and restrictions should also be placed on the amount of data/information returned by the LDAP servers to the client
XML Injection
When the data in a website is stored in a XML database, then this data is accessed by using a method known as XPath generation. In this method, an XPath query is generated after the user provides the input to the system and the required data is accessed.
XML injection occurs when the software does not properly filter or quote special characters or reserved words that are used in XML, allowing an attacker to modify the syntax, contents or commands before execution. The two main types of XML injection are as follows:
- XPATH injection
- XQuery injection
- In XPATH injection the XPath expression that is used to retrieve data from the XML data store is not validated or sanitized prior to processing and built dynamically using user supplied input. The structure of the query can thus be controlled by the user, and an attacker can take advantage of this weakness by injecting malformed XML expressions, allowing the attacker to perform malicious operations such as modifying and controlling logic flow,retrieving unauthorized data and/or circumventing authentication checks.
- XQuery injection works the same way as an XPath injection, except that the XQuery (not XPath) expression that is used to retrieve data from the XML data store is not validated or sanitized prior to processing and built dynamically using user supplied input. Consider the following XML document (accounts.xml) that stores the account information and pin numbers of customers and a snippet of Java code that uses XPath query to retrieve authentication information:
The Java code used to retrieve the home directory based on the provided credentials is:
XPath xpath = XPathFactory.newInstance().newXPath();
XPathExpression xPathExp = xpath.compile(“//customers/customer[user_ name/text()=’” + login.getUserName() + “’ and pin/text() = ‘” + login. getPIN() + “’]/homepage/text()”);
Document doc = DocumentBuilderFactory.newInstance(). newDocumentBuilder().parse(new File(“accounts.xml”));
String homepage = xPathExp.evaluate(doc);
By passing in the value ‘andrew’ into the getUserName() method and the value “’ or ‘’=’”into the getPIN() method call, the XPath expression becomes
//customers/customer[user_name/text()=’andrew’ or ‘’=’’ and pin/text() = ‘’ or ‘’=’’]/hompage/text()
This will allow the user logging in as ‘andrew; to bypass authentication without supplying a valid PIN.
XML Injection
When the data in a website is stored in a XML database, then this data is accessed by using a method known as XPath generation. In this method, an XPath query is generated after the user provides the input to the system and the required data is accessed.
XML injection occurs when the software does not properly filter or quote special characters or reserved words that are used in XML, allowing an attacker to modify the syntax, contents or commands before execution. The two main types of XML injection are as follows:
- XPATH injection
- XQuery injection
- In XPATH injection the XPath expression that is used to retrieve data from the XML data store is not validated or sanitized prior to processing and built dynamically using user supplied input. The structure of the query can thus be controlled by the user, and an attacker can take advantage of this weakness by injecting malformed XML expressions, allowing the attacker to perform malicious operations such as modifying and controlling logic flow,retrieving unauthorized data and/or circumventing authentication checks.
- XQuery injection works the same way as an XPath injection, except that the XQuery (not XPath) expression that is used to retrieve data from the XML data store is not validated or sanitized prior to processing and built dynamically using user supplied input. Consider the following XML document (accounts.xml) that stores the account information and pin numbers of customers and a snippet of Java code that uses XPath query to retrieve authentication information:
The Java code used to retrieve the home directory based on the provided credentials is:
XPath xpath = XPathFactory.newInstance().newXPath();
XPathExpression xPathExp = xpath.compile(“//customers/customer[user_ name/text()=’” + login.getUserName() + “’ and pin/text() = ‘” + login. getPIN() + “’]/homepage/text()”);
Document doc = DocumentBuilderFactory.newInstance(). newDocumentBuilder().parse(new File(“accounts.xml”));
String homepage = xPathExp.evaluate(doc);
XPathExpression xPathExp = xpath.compile(“//customers/customer[user_ name/text()=’” + login.getUserName() + “’ and pin/text() = ‘” + login. getPIN() + “’]/homepage/text()”);
Document doc = DocumentBuilderFactory.newInstance(). newDocumentBuilder().parse(new File(“accounts.xml”));
String homepage = xPathExp.evaluate(doc);
By passing in the value ‘andrew’ into the getUserName() method and the value “’ or ‘’=’”into the getPIN() method call, the XPath expression becomes
//customers/customer[user_name/text()=’andrew’ or ‘’=’’ and pin/text() = ‘’ or ‘’=’’]/hompage/text()
This will allow the user logging in as ‘andrew; to bypass authentication without supplying a valid PIN.
Preventing XML Injection
The prevention of XML injection can be done by properly managing and sanitizing any user input before it is allowed to reach the main program code.The best method is to consider all the user input as unsafe and to properly monitor this input. Most types of the XML injection attacks can be prevented by simply removing all the single and double quotes from the user input. Though this method is very convenient but proper care needs to be taken.
Preventing XML Injection
The prevention of XML injection can be done by properly managing and sanitizing any user input before it is allowed to reach the main program code.The best method is to consider all the user input as unsafe and to properly monitor this input. Most types of the XML injection attacks can be prevented by simply removing all the single and double quotes from the user input. Though this method is very convenient but proper care needs to be taken.
Dubai