1

I am new to web developing and I decided to learn some html-php. I noticed that when submitting a form, the user can actually click "inspect element" and change the form action before the form is submitted. Is there a way around this as a developer?

example

EDIT: This was marked as duplicate. My question was not how to stop the user from changing the html on his browser. My question was how work around this, be safe and not have my php scripts run whenever a user wants to.

Theo Stefou
  • 389
  • 2
  • 16
  • As @ADyson already stated it is not possible, because you cannot restrict a user from doing what he wants in his browser. In addition, to do any harm to your system or website, his changed (php-)file should be executed on your server, which is not possible... so, no risk for you. – Iamnino Mar 21 '18 at 13:58
  • @NPcompete Well, I didn't say that they would run their own script. Just that they would be running my scripts whenever they wanted to. Check the edit. Thanks! – Theo Stefou Mar 21 '18 at 14:24
  • @TheoStefou — NPcompete didn't say that either, but in practise, as soon as you send the page to the user to run in their browser, it **is** their script. – Quentin Mar 21 '18 at 14:28
  • @Quentin, not sure this is a duplicate of that. The standard approach to prevent a form being submitted to/from somewhere else, is to use CSRF prevention. CSRF prevention is essentially a mechanism which grants permission to submit a form, and the PHP script needs to validate that the form was submitted with permission. – Lee Kowalkowski Mar 21 '18 at 14:29
  • "My question was how work around this" — Read the accepted answer on the duplicate. It covers that. – Quentin Mar 21 '18 at 14:29
  • @TheoStefou Ok, I answered before your edit. Sorry for the misunderstanding. In that case the only thing you can do is validating inputs and sessions. Another thing could be the naming convention. Use customized and project related file names, don't just use "standard" names that anyone could guess ;-) – Iamnino Mar 21 '18 at 14:30
  • 1
    @LeeKowalkowski — CSRF protection won't help in this case. It is about not trusting the user, not about stopping a third party tricking a trusted user into submitting untrustworthy data. – Quentin Mar 21 '18 at 14:30
  • @Quentin, if you do CSRF protection properly, every token must be unpredictable and unique, so yes it does help, if a user submits a form that the server did not generate. Specifically if you change the forms `action` attribute, which is what the OP is asking. – Lee Kowalkowski Mar 21 '18 at 14:32
  • @LeeKowalkowski — The token doesn't need to be *predictable* for the user to know what it is. The server has to tell the browser what the token is so the browser can send it back to the server. The user controls the browser, so they can read the token from the browser. They just need to make a request to the page which generates the form *intended* for the other action so they can get a token for it. – Quentin Mar 21 '18 at 14:32
  • @Quentin, but the user should not know what the token is for the other forms. – Lee Kowalkowski Mar 21 '18 at 14:33
  • Basically, OP: user changes form's action, Duplicate: user changes other fields... therefore, not really a duplicate. – Lee Kowalkowski Mar 21 '18 at 14:35
  • 1
    @LeeKowalkowski — If that (*the user should not know what the token is for the other forms*) is true, then, to defend against this problem, you need Authn/Authz not CSRF. (You should have CSRF to defend against CERF attacks as well, but this isn't a CSRF attack). – Quentin Mar 21 '18 at 14:35
  • 1
    @LeeKowalkowski — Both questions are about a user modifying the DOM of a page to submit an HTTP request with unexpected content. There are no significant differences between them. – Quentin Mar 21 '18 at 14:36
  • 1
    @Quentin - No, Authorisation and Authentication may still pass and the user can try and CSRF their way through. The website may not even need authorisation or authentication.... – Lee Kowalkowski Mar 21 '18 at 14:37
  • 1
    @LeeKowalkowski — No. A CSRF attack involves a user being tricked into submitting a bad request by a malicious **third party**. There is no third party involved here. The defences against CSRF attacks depend on the third party being unable to get the token which is a secret between the server and the user. They can't work when the attacker **is** the user because then any secret you tell the user you also tell the attacker. – Quentin Mar 21 '18 at 14:39
  • @Quentin, I know that, I mean the CSRF protection solves the issue of self-unsolicited requests, too. – Lee Kowalkowski Mar 21 '18 at 14:40
  • What on earth is a "self-unsolicited request"? – Quentin Mar 21 '18 at 14:40
  • @Quentin: The OP's question. – Lee Kowalkowski Mar 21 '18 at 14:41
  • 1
    @LeeKowalkowski — It doesn't, because the user can make an additional request to the token issuing page, get the token from it, and insert it into the current page. – Quentin Mar 21 '18 at 14:42
  • 1
    @Quentin Um... assuming the user is able to reach the token issuing page??? In which case, they would just use that page and then that would be pointless. – Lee Kowalkowski Mar 21 '18 at 14:44
  • @LeeKowalkowski — If they can't reach the token issuing page, then that would be because it has Authentication that forbids them access. The problem can be solved (much more simply) by applying the same Authentication rules to the URL that processes the submitted data. – Quentin Mar 21 '18 at 14:47
  • 1
    @Quentin, no it could be application or session state, there doesn't need to be authorisation or authentication. Well, it's not necessarily implied by the OP, anyway – Lee Kowalkowski Mar 21 '18 at 14:47
  • If it is something about the application or session state then it **is** authorisation. – Quentin Mar 21 '18 at 14:49
  • @Quentin, no, it could be an anonymous survey. – Lee Kowalkowski Mar 21 '18 at 14:50
  • Regardless, this question is not very well answered by its duplicate. – Lee Kowalkowski Mar 21 '18 at 14:50
  • If it is an anonymous survey that some people can't answer, then there is still some kind of authorisation going on to prevent the other people from answering it! – Quentin Mar 21 '18 at 14:51
  • @Quentin, I think it may be a stretch to say 'users cannot submit page 3 of a survey before submitting page 1' is an authorisation problem, it's just a session state validation failure. – Lee Kowalkowski Mar 21 '18 at 14:56
  • I'm not quite intending to participate in that debate, but that is not a suitable duplicate target. The answer should be along the lines of "don't put your php files in the public directory" and "implement security". This has nothing to do with preventing html edition. – Félix Adriyel Gagnon-Grenier Mar 23 '18 at 12:08

1 Answers1

3

No, because the user can do whatever they like in the browser. That's not specific to PHP. But presumably it won't work very well because that other PHP script is not set up to deal with that particular form submission (or maybe any form submission at all).

It could be an attack vector, yes, but hopefully you set your scripts up to properly validate the inputs they get.

ADyson
  • 57,178
  • 14
  • 51
  • 63
  • 1
    Yep. Validate inputs, put scripts users shouldn't be executing behind a login, rate limit load-sensitive endpoints, etc. – ceejayoz Mar 21 '18 at 14:22