0

I have a flask web application which is configured with HSTS (no man in middle) and it has a login form.

Inputs to the login form have necessary constraints and HTML disallows incorrect formats. My question is if a user is on my site's login page, he would have the keys to the secure connection. Is it possible that he sends a malicious post request which doesn't follow the constraints of the html form on his side? How probable and difficult is it?

Can anything be done that such a thing is prevented at the client end itself?

Improve this question
1
  • 1
    What do you mean by 'he would have the keys to the secure connection'?
    – Teun Vink
    Aug 5, 2020 at 18:41

2 Answers 2

Reset to default
2

Any validation done client-side shouldn't be trusted, because it can easily be ignored, bypassed or broken. It's trivial to post requests to your login form handler without using the actual page hosting the form, so that handler should always validate all input it receives.

Improve this answer
2
  • I guess SSL would also have temporary keys public and private where each node encrypts with public and other decrypts with private
    – sagar_acharya
    Aug 5, 2020 at 18:44
  • 2
    @caissalover: This is not how SSL/TLS works.
    – Steffen Ullrich
    Aug 5, 2020 at 19:38
2

if a user is on my site's login page, he would have the keys to the secure connection

I don't know what you meant by that...

Client-side protection is more of a help than a protection. If a field on the form must be an email, a client-side email validation will help the user know that the email is invalid before sending the form, and having to probably fill the form all again, while saving on bandwidth and processing on the server-side. But it does not protect the application.

But nobody has to use the client. There are browsers that don't support Javascript (lynx, links, w3m, among others), there are clients that use HTTP libraries instead without any rendering, there are command-line HTTP clients (wget, curl, and PowerShell bindings too), and those "access methods" will not care about the scripts you put in place, or not even see them at all.

A user could just fire up openssl s_client -connect example.org 443, for example, and type HTTP commands straight to the server. As HSTS is only a protection on the browser side, it means nothing here. And Javascript too, or maxlength attribute on form fields, or anything you put in place.

So never trust the client, not even the protections you put on the client-side. It is a time-saving feature, not a protection. Protect the server-side, always.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .