Top 3 HTML5 Vulnerability Risk Categories

Aug 08, 2012 | 04:44 AM | 

New advice out from Forrester Research during the past week urges companies to step up the pace of their HTML5 adoption to keep up with mobility trends and enable better online customer experiences. But as HTML5 gains relevance in the enterprise, developers need to think carefully about the vulnerabilities that their new code may introduce into their organizations' Web infrastructure.

Click here for more of Dark Reading's Black Hat articles.

"We are at an inflection point," Peter Sheldon, an analyst for Forrester, wrote yesterday in a blog post. "With consumer adoption of HTML5-'capable' desktop browsers widespread and web developer understanding of the technology rapidly maturing, HTML5 is no longer an emerging toolset for mobile and tablet development. Instead, it is fast becoming the de facto standard for web experience innovation across touch points."

He says that leading brands, such as Apple, Best Buy, and Four Seasons Hotels, are taking advantage of advanced HTML5 to enhance customers' online experience, and that e-business teams within other enterprises need to leverage the specification for improved competitive differentiation. It needn't involve a wholesale rip-and-replace of existing code, as HTML5 is essentially an extension of existing W3C HTML standards, he explains.

"The decision to start using HTML5 or CSS3 does not require any changes to or throwing away of existing code," Sheldon said. "Instead, e-business teams can simply enhance the user experience of existing sites by incrementally using the new features of HTML5. HTML5 puts more tools in the box, but it doesn’t change the fundamentals of how to build the website."

If organizations are to do it right, though, one of those fundamentals needs to be a thorough secure coding process. As one Indian researcher highlighted at Black Hat recently, the rich capabilities afforded by HTML5 open up a whole new world of attack opportunities for hackers.

"HTML5 has lots of components that, if they are not securely coded, can cause a number of new attack vectors," said Shreeraj Shah, founder and director of Blueinfy Solutions. "By leveraging these vectors, one can craft stealth attacks and silent exploits [that are] hard to detect and easy to compromise."

He explained at the show that in many cases a full-fledged HTML5 site offers enough functionality that it could almost be likened to a small operating system running in the browser. With HTML5 it is possible to create sites that locally store small databases on the client. As he demonstrated in his talk, components like local storage, enhanced XMLHttpRequest (XHR), Document Object model (DOM), and webSQL that make advanced features possible greatly increase a user's attack surface if coded improperly.

In his talk, Shah ran through a number of different vulnerabilities and demonstrated proof-of-concepts for many, with all of them falling under three main categories.

1. XHR And Tag Vulnerabilities
The first, XHR and tag vulnerabilities, stem from enhancements to XHR in HTML5 that changes HTTP request and response to allow cross-domain calls by following what is called the Cross Origin Resource Sharing (CORS) policy. This change greatly enhances the potency of Cross Site Request Forgery (CSRF) attacks, enabling more stealthy CSRF attacks that can send CSRF on the raw stream of data from the browser and which can not only be sent with the request, but also sent back with the response.

"So it is like crosssite response extraction," he said.

Also in this category, Shah lumped in Cross Site Scripting (XSS) attacks that take advantage of the surfeit of new tags, attributes, and events offered up through HTML5.

"This is definitely an interesting attack vector to bypass an existing blacklist or whitelist because these are a whole new set of tags that can possibly cause XSS," he said.

2. Thick Feature Vulnerabilities
The next category of vulnerabilities Shah called out stem from the fat client functionality brought forth by HTML5. The support of local storage and session storage through HTML5's storage API makes it possible for attackers to use XSS to do blind enumeration of local storage variables and eventually get access to local storage. Similarly, if a local file system is created using SQL Lite to store a database locally, attackers can potentially run SQL injection attacks against that database through attacks leveraging blind WebSQL enumeration.

"So we are still dealing with SQL injection on the server side and now we have SQL injection on the client side using XSS," he said.

3. DOM Vulnerabilities
Finally, the third big category that Shah ran through were vulnerabilities around DOM.

For example, HTML5 now makes it possible for developers to create an HTML-5 based application that runs on a single DOM without any refreshes necessary. This is a boon for performance, but it also makes DOM-based XSS a "sleeping giant" in Shah's mind.

"Essentially, what is going to happen is when you have a DOM-based XSS, that XSS will remain throughout the application life cycle," he said.

In the same vein, HTML5's support of caching pages for offline usage opens the possibility of cache poisoning. And the way that the widgets, gadgets, and modules popular with HTML5 applications share.

As Shah noted in a paper written in conjunction with his talk, the vendor-neutral, browser-native nature of HTML5 is finally starting to gain the specification traction within developer communities. He noted that the attacks he detailed are just the tip of the iceberg because "HTML5 is just warming up."

As different libraries and ways of development continue to emerge, new attack surfaces are bound to come up. That is why Shah said he believes developers need to start thinking about these possible vulnerabilities from the outset of their HTML5 initiatives.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

SQL injection

From Wikipedia, the free encyclopedia

SQL injection is a technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is in fact an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another.

Software Testing portal

[edit] Forms of SQL injection vulnerabilities

[edit] Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. This results in the potential manipulation of the statements performed on the database by the end user of the application.

The following lines of code illustrates this vulnerability:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

This SQL code is designed to pull up the records of a specified username from its table of users. However, if the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the "userName" variable as

a' or 't'='t

renders this SQL statement by the parent language:

SELECT * FROM users WHERE name = 'a' OR 't'='t';

If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of 't'='t' is always true.

While most SQL Server implementations allow multiple statements to be executed with one call, some SQL APIs such as php's mysql_query do not allow this for security reasons. This prevents hackers from injecting entirely separate queries, but doesn't stop them from modifying queries. The following value of "userName" in the statement below would cause the deletion of the "users" table as well as the selection of all data from the "data" table (in essence revealing the information of every user):

a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '%

This input renders the final SQL statement as follows:

SELECT * FROM Users WHERE name = 'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%';

[edit] Incorrect type handling

This form of SQL injection occurs when a user supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example:

statement := "SELECT * FROM data WHERE id = " + a_variable + ";"

It is clear from this statement that the author intended a_variable to be a number correlating to the "id" field. However, if it is in fact a string then the end user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

1;DROP TABLE users

will drop (delete) the "users" table from the database, since the SQL would be rendered as follows:

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

[edit] Vulnerabilities inside the database server

Sometimes vulnerabilities can exist within the database server software itself, as was the case with the MySQL server's mysql_real_escape_string() function^[1]. This would allow an attacker to perform a successful SQL injection attack based on bad Unicode characters even if the user's input is being escaped.

[edit] Blind SQL Injection

Blind SQL Injection is used when a web application is vulnerable to SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must be crafted for each bit recovered. There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established.^[2]

[edit] Conditional Responses

One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen.

SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1

will result in a normal page while

SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2

will likely give a different result if the page is vulnerable to a SQL injection. An injection like this will prove that a blind SQL injection is possible, leaving the attacker to devise statements that evaluate to true or false depending on the contents of a field in another table.^[3]

[edit] Conditional Errors

This type of blind SQL injection causes a SQL error by forcing the database to evaluate a statement that causes an error if the WHERE statement is true. For example,

SELECT 1/0 FROM users WHERE username='Ralph'

the division by zero will only be evaluated and result in an error if user Ralph exists.

[edit] Time Delays

Time Delays are a type of blind SQL injection that cause the SQL engine to execute a long running query or a time delay statement depending on the logic injected. The attacker can then measure the time the page takes to load to determine if the injected statement is true.

[edit] Preventing SQL Injection

To protect against SQL injection, user input must not directly be embedded in SQL statements. Instead, user input must be escaped or filtered or parameterized statements must be used.

[edit] Using Parameterized Statements

In some programming languages such as Java and .NET parameterized statements can be used that work with parameters (sometimes called placeholders or bind variables) instead of embedding user input in the statement. In many cases, the SQL statement is fixed. The user input is then assigned (bound) to a parameter. This is an example using Java and the JDBC API:

PreparedStatement prep = conn.prepareStatement("SELECT * FROM USERS WHERE USERNAME=? AND PASSWORD=?");

prep.setString(1, username);

prep.setString(2, password);

The same goes for C#:

using (SqlCommand myCommand = new SqlCommand("select * from Users where UserName=@username and Password=@password", myConnection))

                {                    

                    myCommand.Parameters.AddWithValue("@username", user);

                    myCommand.Parameters.AddWithValue("@password", pass);

 

                    myConnection.Open();

                    SqlDataReader myReader = myCommand.ExecuteReader())

                    ...................

                }

In ASP:

userName=replace(request.querystring("username"))     

userPassword=replace(request.querystring("Password"))

 

userName=replace(userName,"'","\'")

 

'userPassword it's a numeric value.

userPassword=cdbl(userPassword)

 

myConn.execute "select * from users where name='" & userName & _

               "' and userPassword=" & userPassword & " limit 1"

In PHP, it's usual to just escape the parameters before sending the SQL query:

$query = sprintf("SELECT * FROM Users where UserName='%s' and Password='%s'", 

                  mysql_real_escape_string($Username), 

                  mysql_real_escape_string($Password));

mysql_query($query);

For PHP version 5 and MySQL version 4.1 and above, however, you can use a vendor specific extension like mysqli for "true" prepared statement queries.^[4] Example:^[5]

$db = new mysqli("localhost", "user", "pass", "database");

$stmt = $db -> prepare("SELECT priv FROM testUsers WHERE username=? AND password=?");

$stmt -> bind_param("ss", $user, $pass);

$stmt -> execute();

The mysql_real_escape_string adds backslashes (\) to escaped characters like single quotes ' and double quotes ". Though, you should read this

The magic_quotes_gpc PHP configuration directive affects Get, Post and Cookie values. If turned on, value (It's "PHP!") will automagically become (It\'s \"PHP!\").

In ColdFusion, the CFQUERYPARAM statement is useful in conjunction with the CFQUERY statement to nullify the effect of SQL code passed within the CFQUERYPARAM value as part of the SQL clause.^{[6] [7]}. An example is below.

<cfquery name="Recordset1" datasource="cafetownsend">

SELECT *

FROM COMMENTS




WHERE COMMENT_ID =<cfqueryparam value="#URL.COMMENT_ID#" cfsqltype="cf_sql_numeric">

</cfquery>

[edit] Enforcing the Use of Parameterized Statements

There are two ways to ensure an application is not vulnerable to SQL injection: using code reviews (which is a manual process), and enforcing the use of parameterized statements. Enforcing the use of parameterized statements means that SQL statements with embedded user input are rejected at runtime. Currently only the H2 Database Engine supports this feature.

Attackers use SQL injection to do anything from circumvent authentication to gain complete control of databases on a remote server.

SQL, the Structured Query Language, is the de facto standard for accessing databases. Most web applications today use an SQL database to store persistent data for the application. It is likely that any web application you are testing uses an SQL database in the backend. Like many languages, SQL syntax is a mixture of database instructions and user data. If a developer is not careful, the user data could be interpreted as instructions, and a remote user could perform arbitrary instructions on the database.

Consider, for example, a simple web application that requires user authentication. Assume that this application presents a login screen asking for a username and password. The user sends the username and password over some HTTP request, whereby the web application checks the username and password against a list of acceptable usernames and passwords. Such a list is usually a database table within an SQL database.

A developer can create this list using the following SQL statement:

CREATE TABLE user_table (
  id INTEGER PRIMARY KEY,
  username VARCHAR(32),
  password VARCHAR(41)
);

This SQL code creates a table with three columns. The first column stores an ID that will be used to reference an authenticated user in the database. The second column holds the username, which is arbitrarily assumed to be 32 characters at most. The third column holds the password column, which contains a hash of the user’s password, because it is bad practice to store user passwords in their original form.

We will use the SQL function PASSWORD() to hash the password. In MySQL, the output of PASSWORD() is 41 characters.

Authenticating a user is as simple as comparing the user’s input (username and password) with each row in the table. If a row matches both the username and password provided, then the user will be authenticated as being the user with the corresponding ID. Suppose that the user sent the username lonelynerd15 and password mypassword. The user ID can be looked up:

SELECT id FROM user_table WHERE username='lonelynerd15' AND
password=PASSWORD('mypassword')

If the user was in the database table, this SQL command would return the ID associated with the user, implying that the user is authenticated. Otherwise, this SQL command would return nothing, implying that the user is not authenticated.

Automating the login seems simple enough. Consider the following Java snippet that receives the username and password from a user and authenticates the user via an SQL query:

String username = req.getParameter("username");
String password = req.getParameter("password");
String query = "SELECT id FROM user_table WHERE " +
    "username = '" + username + "' AND " +
    "password = PASSWORD('" + password + "')";

ResultSet rs = stmt.executeQuery(query);

int id = -1; // -1 implies that the user is unauthenticated.

while (rs.next()) {
      id = rs.getInt("id");
}

The first two lines grab the user input from the HTTP request. The next line constructs the SQL query. The query is executed, and the result is gathered in the while() loop. If a username and password pair match, the correct ID is returned. Otherwise, the id stays -1, which implies the user is not authenticated.

If the username and password pair match, then the user is authenticated. Otherwise, the user will not be authenticated, right?

Wrong! There is nothing stopping an attacker from injecting SQL statements in the username or password fields to change the SQL query.

Let’s re-examine the SQL query string:

String query = "SELECT id FROM user_table WHERE " +
    "username = '" + username + "' AND " +
    "password = PASSWORD('" + password + "')";

The code expects the username and password strings to be data. However, an attacker can input any characters he or she pleases. Imagine if an attacker entered the username ‘OR 1=1 -- and password x; then the query string would look like this:

SELECT id FROM user_table WHERE username = '' OR 1=1 -- ' AND password
= PASSWORD('x')

The double dash (--) tells the SQL parser that everything to the right is a comment, so the query string is equivalent to this:

SELECT id FROM user_table WHERE username = '' OR 1=1

The SELECT statement now acts much differently, because it will now return IDs where the username is a zero length string ('') or where 1=1; but 1=1 is always true! So this statement will return all the IDs from user_table.

In this case, the attacker placed SQL instructions ('OR 1=1 --) in the username field instead of data.

• ' OR 1=1 --

• ') OR 1=1 --

Error executing query: You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near 'SELECT (title, body) FROM blog_table WHERE
cat='OR 1=1' at line 1

String query = "SELECT id FROM user_table WHERE " +
    "username = '" + username + "' AND " +
    "password = PASSWORD('" + password + "')";

' OR 1=1; DROP TABLE user_table; --

SELECT id FROM user_table WHERE username='' OR 1=1; DROP TABLE
user_table; -- ' AND password = PASSWORD('x');

SELECT id FROM user_table WHERE username='' OR 1=1; DROP TABLE
user_table;