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:
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 InformationUse 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.
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
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:
%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):
The following request and response is an example of a successful attack:
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
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.
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?
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:
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.
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.