How to validate data securely in the frontend?

Asked

Viewed 173 times

0

According to that comment by @Pauloalexandre, it would be possible to validate the data only on the front, so that the back only receives the ready data

I know that it is possible to limit, through CORS, the origin of the requisition among other things

But is it really possible to do what I mentioned above? How?

http security-guard http-request
  • 2

    This breaks rule number 1 of the web: never trust your client’s data.

  • 1

    What if the attacker makes an XSS on your website and requests your own domain? In an ideal case, that you close any and all security loopholes, who knows, you might even trust, but who’s going to guarantee that you closed them all? I find it a lot less work to do the validation in the backend too - and certainly a lot cheaper.

  • @Andersoncarloswoss could give an answer by deepening all this?

  • No, never validate the data only on the front. The browser itself gives you the possibility to edit a request, so its limitation in CORS is worthless.

2 answers

1


You should never believe a customer’s information, this is the basic rule.

You can include client-side filters and validations in order to provide a better user experience, as errors will be immediate, not having to wait for server response.

But you must do the same check on the server.

There is no way to know the "request origin", forget it. CORS only affects the context of the browser, it is not the only form of communication with websites. CORS is made so that the browser, honest, do not allow connections between sites.

You can simply "swindle" using the Curl, for example:

curl ^
-H "Origin: seusite.com" ^
-H "Referer: https://seusite.com" ^
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36 OPR/54.0.2952.54" ^
-d "nome=12345&email=xxxxxx&senha=000" ^
-X POST ^
https://seusite.com/registrar

Note that we are pretending to be in seusite.com adding the headers of Origin and Referer, which will mislead any "source" validation. In addition, we add the User-Agent to pretend to be a common browser. After that we send any arbitrary information, such as: nome=12345&email=xxxxxx&senha=000, if the filter is only on customer, we completely ignore.

  • In this way, it is also possible to send a false ip?

  • 1

    @Guilhermecostamilam, it depends. If you believe the headlines, yes.. But, apart from this situation, TCP (and consequently HTTP) has no way to fake the IP due to Handshake, the most that can is using proxies, which is not a "fake" in itself. But if for some reason you are using UDP, you may have problems with IP spoofing.

0

Not! From an attacker’s point of view, there is no "secure validation on the front end", it will simply be ignored.

As much as you limit the origin of the request(CORS), it is extremely simple to edit the content of a request using tools like Burpsuite or even through the browser itself. That is, it is possible to send a valid request containing a malicious payload.

Browser other questions tagged http security-guard http-request

You are not signed in. Login or sign up in order to post.