The OWASP Top Vulnerability is (still) Injection

The figure below outlines how input provided by a user is processed by the application.

On the server a query is assembled containing user input.

The user input is inserted into the query (here as values in the WHERE clause).

The complete query is passed to the database and interpreted (run).

The result is passed back to the program, which then assembles the output for the web server.

The result is passed back to the program, which then assembles the output for the web server.

Now consider the following, atypical input.

Without knowing the exact details of the database (but assuming that a suitable database exists), what do you think the query will return?

NB: SQL string delimiters are single quotes.

It is likely, that in an insecure application such input permits access to the system without actually requiring the password.

Because 1==1 will always return true. As this is connected to the rest of the query with OR, the query will always return true.

SQL Injection – Sample Payloads

A payload is a portion of malicious software (or malware) that performs malicious actions.

There are my different payloads for injection attacks.

  SELECT title, year FROM books WHERE publisher = ‘Wiley’--’ and  published = 1;
SELECT * FROM users WHERE username = ‘tim’ AND password = ‘123’; 
    	enter username: admin’ - -
SELECT * FROM users WHERE username = ‘’ AND password = ‘’ 
        enter: ’ OR 1 = 1

Depending on the purpose of the site and underlying queries used, injection attacks are not limited to select statements.

Assuming the following normal statement:

  INSERT INTO users (username, password, ID, privs) 
VALUES (‘daf’, ‘secret’, 2256, 1);

enter:

  foo’, ‘bar’, 9999, 0)- -

Privileges 0 often means an admin user

This sets up a new user with admin rights and not user rights as intended

In fact crafting payloads that penetrate systems often without knowing the exact underlying queries is quite an art form.

Defence Mechanism 1 Use Prepared Statements

In database management systems, a prepared statement or parameterized statement is a feature used to execute the same or similar database statements repeatedly with high efficiency.

A statement template is created by the application and sent to the database management system (DBMS), certain values are left unspecified.

INSERT INTO PRODUCT (name, price) VALUES (?, ?)

The DBMS parses, compiles, and performs query optimization on the statement template, and stores the result without executing it.

At a later time, the application supplies (or binds) values for the parameters, and the DBMS executes the statement.

The original statement template is not derived from external input, no SQL Injection.

Defence Mechanism 2 User Input Sanitation

Remove suspicious characters from user input programmatically before using the input, e.g. '

Strategies:

white lists, only allow certain known good words in user input

black lists, disallow certain bad characters and words in user input

Difficulty: the almost infinite number of ways of representing an payload

Broken Authentication: The Problem

Attackers have access to a large quantity, e.g. hundreds of millions of valid username and password combinations.

In addition there are tools that can generate user names from email addresses, passwords from dictionaries or by combining a range of input characters. Tools can also automatically generate request calls given a domain by using frequently used URL paths.

Hackers use these for brute force attacks, typically aided by tools or scripts that automatically generate requests against lists of URLs, ranges of ports using files of user-names and passwords or automatically generate those from dictionaries. They may also target known default or administration accounts of known software.

This also involves session hijacking attacks where tokens from unclosed sessions are either retrieved from web browsers that are left accessible in public places or where session tokens are predictable and can be guessed or auto generated.

Vulnerability Prevention Methods

Implement multi-factor authentication, which prevents automated attacks.

Do not ship or deploy with any default credentials, particularly for admin users.

Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.

Set up rules for minimal password lengths and combination of characters that inhibit the use of dictionary words.

Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.

Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login.

Do not transmit session IDs in the URL, as these can be cached and retrieved later.

Keep sessions only alive for a reasonable period of time and while active. Otherwise let the user log on again.

Sensitive Data Exposure

Hackers attempt to steal clear text, i.e. unencrypted sensitive data.

This may happen in various ways, such as by intercepting the communication between client and server,

By accessing unattended web browsers in public places, such as internet cafes.

By stealing clear text data from the server.

Prevention Methods

Classify data processed, stored, or transmitted by an application. Identify sensitive data. Examples of sensitive data are: user names, passwords, payment related data etc.

Don’t store sensitive data unnecessarily, e.g. it is very convenient to record the user access details in cases of application failures in log files because that makes it easier to re-create the error.

However, even if an application has been properly secured hackers may attack the company’s network and gain access to log files from which user credentials can be easily lifted if available.

Encrypt all sensitive data in transit with secure protocols, such as HTTPS. There are attempts to make communication between client and server https only on the web.

Disable caching for responses that contain sensitive data.

Store passwords using strong adaptive and salted hashing functions with a delay factor.

Cross-site Scripting (XSS)

An attacker sends a crafted link to the victim that contains malicious JavaScript code.

The victim executes the link.

The JavaScript runs in the victim’s browser and completes the instructions coded by the attacker.

This may be used to generate a request to a server controlled by the hacker, which includes life session data. The hacker can then impersonate the victim.

There are three types of XSS: stored XSS, reflected XSS and DOM-based XSS. We will focus on stored XSS in the context of this module.

Stored XSS

Some applications store user generated contents, e.g. user reviews, blogs, descriptions of items for online auctions etc.

These materials are often made accessible to other users.

As part of typical application behaviour the user generated contents are incorporated in HTML pages sent to other users as HTTP responses. That is normal application behaviour.

The result is that these pages are then viewed in the user agents of other users, i.e. downloaded on to user computers and interpreted in the browsers on those computers.

Some user generated contents may be ‘atypical’ and will be executed in the browsers of those users.

Note that the application itself has not been compromised but rather the intended behaviour of the application is used to facilitate the attack.

The target of this attack are other users using a vulnerable application.

The OWASP materials available in the Additional Learning Materials section contain further information about XSS.

Sample Payload

Consider the following code snippet:

<IMG SRC=javascript:alert('XSS')>

When this is rendered in a user’s browser the browser attempts to load the image and executes that code.

Although this snipped is harmless as it just displays an annoying alert box, it is important to notice that the tag is executed.

In reality such code could send a request to the sever controlled by the hacker and make session tokens available to the hacker.

The hacker can then impersonate the innocent user.

This is of particular significance if the user has advanced system privileges.

An example of how such an attack has been used to infiltrate one of the most powerful IT companies (who are thankfully very open about this issue) is available in the Additional Learning Materials section on GCULearn.

Prevention

Payloads rely on being executed in the browser. Therefore the aim is to render the payloads non-executable.

Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL).

Use entity encoding. Examples include:

Use the escape syntax on the part of the HTML document you're putting untrusted data into, e.g. a <div>s element.

Only place untrusted contents in defined allowed place in the HTML page, such as in designated <div> elements.

Screen user input for HTML or JavaScript code unless that is explicitly permitted, e.g. in issue tracking systems.

When writing single page applications also escape untrusted data placed inside of JavaScript, HTML attributes and CSS statements.

Wherever possible use libraries to sanitize code as this is less error prone compared with writing your own sanitation code.

Also ensure proper session management as studied before.