HTML5 Security Risk Analysis 3: WebSQL attacks

Previous connection:

HTML5 security risk details: CORS attacks
HTML5 Security Risk Analysis II: Web Storage attacks

1. Introduction to WebSQL Security Risks
 
Database security has always been a matter of widespread concern and need to be prevented by backend personnel. However, since HTML5 introduced local databases and WebSQL, front-end development must be aware of and cautious about database security. The security problem of WebSQL is usually manifested in two parts:
 
First, SQL injection: Like local databases, attackers can use SQL injection points to attack databases.
 
On the other hand, if the Web App has an XSS vulnerability, the local data is easily leaked. You can think about the situation where the local database stores the user's recent transaction records or private messages.
 
Ii. WebSQL security risk details
 
1. SQL Injection
 
For example, we have a URL: http:/blog.csdn.net/hfahe? Id = 1, which receives an id parameter for local database query and output. The corresponding SQL statement is "select name from user where id = 1 ".
 
 
 
However, for this simple SQL query, attackers can construct a false input data "1 or 1 = 1 ", then our SQL statement will change to "select name from user where id = 1 or 1 = 1 ". This is quite bad, because the condition 1 = 1 is always true, then this statement will traverse all the records in the user table of the database and output them in the same row.
 
 
 
In this way, attackers can construct SQL statements of multiple attacks to manipulate users' local database records.
 
2. XSS and Database Operations
 
In the case of an XSS vulnerability, attackers need to perform the following steps to obtain local data:
 
1) Obtain JavaScript database objects
 
2) obtain the table structure on SQLite
 
3) Get the data table name
 
4) operation data
 
For example, the following script completes the above steps. I can run it on the Chrome console to obtain the table name of the user's local database. Using this table name, attackers can use any SQL statement to perform the attack.
 
 
Var dbo;
Var table;
Var usertable;
For (I in window ){
Obj = window [I];
Try {
If (obj. constructor. name = "Database "){
Dbo = obj;
Obj. transaction (function (tx ){
Tx.exe cuteSql ('select name FROM sqlite_master WHERE type = \ 'table \ '', [], function (tx, results ){
Table = results;
}, Null );
});
}
} Catch (ex ){}
}
If (table. rows. length> 1)
Usertable = table. rows. item (1). name;
 
Var dbo;
Var table;
Var usertable;
For (I in window ){
Obj = window [I];
Try {
If (obj. constructor. name = "Database "){
Dbo = obj;
Obj. transaction (function (tx ){
Tx.exe cuteSql ('select name FROM sqlite_master WHERE type = \ 'table \ '', [], function (tx, results ){
Table = results;
}, Null );
});
}
} Catch (ex ){}
}
If (table. rows. length> 1)
Usertable = table. rows. item (1). name;
Iii. Defense
 
For WebSQL attacks, www.2cto.com has the following methods to prevent them:
 
1) Check the input type and filter dangerous characters
 
We need to ensure that the input type conforms to expectations. For example, the above id parameter must be of the numeric type, and filter out dangerous keywords and symbols, just like the addslashes function in PHP.
 
2) use the parameter form in SQL statements
 
SQL statements can be in the form of parameters, such
 
 
ExecuteSql ("SELECTname FROM stud WHERE id =" + input_id)
 
ExecuteSql ("SELECTname FROM stud WHERE id =" + input_id)
The format of String concatenation is not safe. You can replace it
 
 
ExecuteSql ("SELECTname FROM stud WHERE id =? ", [Input_id]);)
 
ExecuteSql ("SELECTname FROM stud WHERE id =? ", [Input_id]);)
This ensures that the input of the parameter meets the set type.
 
3) treat every SQL operation with caution
 
Whether it is select, modify, update, or delete, any SQL statement operation you write may become an attacker's attack object, causing significant losses. Therefore, you must be cautious with it.
 
4) do not store important data
 
The local database is always transparent and insecure. Important data must be stored on the server. Without important data in the local database, it will not cause significant losses to users.
 
5) Eliminate XSS vulnerabilities
 
XSS attack defense will be described in a special chapter, which will not be described in detail in this article.