I have a form on my page where users enter their credit card data. Is it possible in HTML to mark the form's action being constant to prevent malicious JavaScript from changing the form's action property? I can imagine an XSS attack which changes the form URL to make users posting their secret data to the attacker's site.

Is it possible? Or, is there a different feature in web browsers which prevents these kinds of attacks from happening?

I have a form on my page where users enter their credit card data. Is it possible in HTML to mark the form's action being constant to prevent malicious JavaScript from changing the form's action property? I can imagine an XSS attack which changes the form URL to make users posting their secret data to the attacker's site.

Is it possible? Or, is there a different feature in web browsers which prevents these kinds of attacks from happening?

• javascript
• html
• forms
• xss
• action

Share Improve this question Follow edited Jan 16, 2015 at 1:40 NoviceCodingGeek 22611 gold badge44 silver badges1717 bronze badges asked Sep 19, 2011 at 19:01 Michał FronczykMichał Fronczyk 1,89155 gold badges2424 silver badges3030 bronze badges 1

• How would the malicious JavaScript get into the form in the first place? Does the payment form allow user submitted content to be displayed (XSS)? That would be an unusual payment form. – Matthew Lock Commented Jan 16, 2015 at 2:11

Add a ment  | 

3 Answers 3

Sorted by: Reset to default 5

This kind of attack is possible, but this is the wrong way to prevent against it. If a hacker can change the details of the form, they can just as easily send the secret data via an AJAX GET without submitting the form at all. The correct way to prevent an XSS attack is to be sure to encode all untrusted content on the page such that a hacker doesn't have the ability to execute their own JavaScript in the first place.

---

More on encoding...

Sample code on StackOverflow is a great example of encoding. Imagine what a mess it would be if every time someone posted some example JavaScript, it actually got executed in the browser. E.g.,

<script type="text/javascript">alert('foo');</script>

Were it not for the fact that SO encoded the above snippet, you would have just seen an alert box. This is of course a rather innocuous script - I could have coded some JavaScript that hijacked your session cookie and sent it to evil./hacked-sessions. Fortunately, however, SO doesn't assume that everyone is well intentioned, and actually encodes the content. If you were to view source, for example, you would see that SO has encoded my perfectly valid HTML and JavaScript into this:

<script type="text/javascript">alert('foo');</script>

So, rather than embedding actual < and > characters where I used them, they have been replaced with their HTML-encoded equivalents (< and >), which means that my code no longer represents a script tag.

Anyway, that's the general idea behind encoding. For more info on how you should be encoding, that depends on what you're using server-side, but most all web frameworks include some sort of "out-of-the-box" HTML Encoding utility. Your responsibility is to ensure that user-provided (or otherwise untrusted) content is ALWAYS encoded before being rendered.

Is there a different feature in web browsers which prevents these kinds of attacks from happening?

Your concern has since been addressed by newer browser releases through the new Content-Security-Policy header.

By configuring script-src, you can disallow inline javascript outright. Note that this protection will not necessarily extend to users on older browsers (see CanIUse ).

Allowing only white-labeled scripts will defeat most javascript XSS attacks, but may require significant modifications to your content. Also, blocking inline javascript may be impractical if you are using a web frameworks that relies heavily on inline javascript.

Nope nothing to really prevent it.

The only thing I would suggest to do is have some server side validation of any information ing to the server from a user form.

As the saying goes: Never trust the user