CODEWITHSUNDEEP
c#javascriptjqueryasp.netajax
Aishwarya Shiva
Aishwarya Shiva

Reputation: 3406

Security measures other than XSS and CSRF prevention that must be taken when using JQuery Ajax and ASP.NET Generic Handlers

I was a pure ASP.NET developer that used toolbox controls to create websites. But when I researched and found that apps created using pure JS/JQuery and generic handlers are more engaging, user attracting and fast in performance, then I studied about them. Now I am creating a website purely based on JS business logic and accessing database using ASP.NET Handlers. I am using ASPX pages for start so that features like bundling and routing will be done by these pages and my development speed will be faster.

When I was thinking about the attacks that can be done using JavaScript, I found that XSS and CSRF are the two attacks that are possible through pure JavaScript. I prevented XSS attack by sanitizing text that is transferred to server. And CSRF attack is prevented by using a CSRF token and saving it to cookies and comparing that cookie value and the token from the Ajax request in Generic Handler. And both of these are working fine.

But then I began to think about any other loop holes that I may have left in the app. Then a scenario came into my mind. Following is the scenario:

Since JS files are all publicly visible, suppose there is a function saveData(data) which sends data that to be saved in database and a CSRF token to the Generic Handler. Now suppose an attacker calls this function by using Inspect Element Feature of browsers like chrome, opera, IE etc. and injects a link like:

<a href="#" onclick="saveData('IHackedYou')">Hack</a>

Now when he clicks this injected 'Hack' link, the saveData() function will send 'IHackedYou' and CSRF token (since it is stored in a global variable in JS file) to the Handler. Handler will authorize this requests because the CSRF token is same as that of cookie and will store unwanted data in the database and it will get worse if the attacker clicked the link a thousand times(or more) manually or using some automated system. This will kill my database server.

So I want to ask what type of attack is this and how should I prevent it?

Upvotes: 2

Views: 161

Answers (1)

Anthony Garcia-Labiad
Anthony Garcia-Labiad

Reputation: 3711

Don't rely on client-side validation

Everything that is done client-side must be checked server-side. This is not new, it apply even where there is no javascript. Suppose the following plain html form:

<form>
  <select name="fruit">
    <option value="banana">Banana</option>
    <option value="apple">Apple</option>
  </select>
</form>

If you don't expect anything else than "banana" or "apple", you have to check it server-side, because it's easy for a malicious user to inject another value.

Same logic goes for your example. Your function saveData is going to communicate with the server in some way (ajax call, websocket or anything). So if 'IHackedYou' isn't a valid input, the server must check it and throw an error.

Don't trust client-side computed values

Imagine you're coding a shop website with a lot of logic in javascript. You will probably have a cart object, like:

{
  "products": [
    {"name": "banana", "price": 2.0, "quantity": 1},
    {"name": "apple", "price": 3.0, "quantity": 2}
  ],
  "totalPrice": 8.0
}

Once the user submit his command, it's tempting to directly use that client-side computed totalPrice, but never do that. The totalPrice should only be used client-side, in order to improve user-experience.

Sometime it's realy anoying, because you have to reimplement the same logic client-side and server-side, that's one reason (among other) why javascript server-side solution become popular these days.

Upvotes: 2

Related Questions