I am developing a cakephp (2.5.6) application where user can entry comments, blog posts and more. The users can use html markup (h1, h2.., quote, ..).
How can i add security to the form inputs so a user can not add javascript code like <script>alert('foo');</script> or anything else.
I have tested it with a simple $this->Form->input('description');. Now if i display the description with echo $data['Post']['description'] the alert is displayed on page refresh.
What is the common way to prevent this? Does cakephp provide any helpers or functions?
Well, you should push all output on a webpage through h() which is the Cake shortcut for htmlspecialchars. Even output you've fetched from an API or a hardware sensor. Who tells you they can't give you malicious data? Most fundamental security rule: Don't trust any data input in your system.
If you need a more detailed sanitizer HTML Purifier which is a lib and CakePHP plugin for it that allows you to come up with specific filtering. For example disallow <script> but allow <b> and <a>. It can even filter allowed HTML attributes. Read the documentation.
Related
I'm building a website similar to twitter. A user can make a post and mention another user using the #username notation.
At first I was going to parse each post server side and add html tags around the #mentions, then render the post as a template.HTML (I'm using Go server side), but then I realized that users would be able to add any html they want, and I don't want that. Is there a way to render the posts as html while ignoring any html that the user tries to upload? Any code/markup that they upload should be shown in plain text.
Or will it be better to add the markup around the #mentions client side using javascript?
Great worry! This type of HTML injection from user input is a real problem, fortunately, there’s an easy fix, you can escape HTML characters so the browser understands that there’s a literal “<“ character in the text, not the start of a HTML element.
In Go, there’s the html.EscapeString, which you pass the user input and then can safely use inside HTML. So you would sanitize the input and after that parse it and link the #mentions.
My limited experience in web development as a self-taught led me to hit a wall while trying to figure out how to deal with this problem.
I need a form (map_settings.php) where the user should enter some inputs. Those inputs must be saved in a database table (MAPS) and then used to create the final HTML file (e.g. map1.html) for that specific user/inputs.
I know how to deal with using forms and saving submitted data to a database.
What is completely obscure to me is how can I use those inputs to automatically generate the final HTML.
My idea is to have a template HTML (template.html) and each time a user saves new settings via the form, I copy the template and replace some variables inside it with the actual data the user has input in the form.
If this might matter, the variables I need to replace in the template are also JavaScript variables within a <script> tag.
Can anybody help me suggesting one viable way to do this? I am mostly using JavaScript and PHP, without frameworks. I've also red about JavaScript templating engines, but I sincerely did not get if those are useful to me in my case.
Anyway, here is an illustration of what I would need to do, to hopefully clarify better my point.
Creating a static HTML file per user is not the way to go. Instead just have a PHP script like mapdisplay.php or similar.
Make the script so that if you type mapdisplay.php?map=1 in the browser then it will read the map ID, get the relevant settings from the database for the map in question and then generate some HTML to display them - of course you can have most of the HTML ready made like a template, and just use PHP to fill in the details from the database. This idea of getting data on the fly when requested, and plugging it into some HTML is how most web applications work.
If you create a static HTML for each user it quickly becomes unmanageable with a large number of users, plus it's hard to introduce changes or improvements to the template because instead of just updating one script file, you have to back and re-do every existing page. There are other disadvantages to your approach too, but I won't continue here - you get the idea I hope.
If I were you I'll make that in this way:
Don't use template.html
Don't get data from database to new file, but from form
Make database test before make file
To make template use
$template_text = "text...text...html...text...".$php_varible."text...text...html...text";
For other things about php see w3schools
This morning I woke up to a JavaScript alert on a project of mine that runs KnockoutJS, jQuery, and Underscore.js. It says "I can run any JavaScript of my choice on your users' browsers". The only third-party JavaScript I am downloading is Typekit, and removing that does not make this go away. I've searched my JavaScript and vendor JavaScript and this string does not come back up matching anything.
How would you troubleshoot this and/or is this something that is known to occur?
If you have a database for your application, that would be the next place to check. I'm guessing somebody found and exploited an Injection vulnerability (either un-sanitized HTML input or SQL) and injected the script into a page via the database.
The last place would be to look at the ruby code to see if somehow a malicious user modified your source.
You obviously take an input from user and then outputting it back as part of HTML without quoting or sanitizing. There's two quick checks to do:
1) Open source of page that outputs this alert and search inside source for exact text of alert - this should give you clear indication of what user-filled field is compromised.
2) To be sure, search all other fields in your database generated by users (login names, text of comments, etc.) for words "script" and "alert".
For future: always sanitize your input (remove HTML tags) before inserting it in HTML page OR escape symbols as entities according to standards OR explicitly treat is a plain text by assigning it to value of text node in DOM.
It sounds like a hack attempt on your site. Check any databases, text files, etc. that are being used that are receiving user input. It sounds like you're not checking what's being posted to your server I'm guessing.
I currently have a simple <div contenteditable="true"> working, but, here's my problem.
Currently, the user can create a persistent XSS by inserting a <script> into the div, which I definitely do not want.
However, my current ideas to fix this are:
Allow only a and img tags
Use a textarea (not a good idea, because then have users copy and paste images)
What do you guys suggest?
You have to keep in mind that to prevent xss, you've GOT TO DO IT ON THE SERVER SIDE. If your rich text editor (ex YUI or tinyMCE) has some javascript to prevent a script tag from being inputted, that doesn't stop me from inspecting your http post requests, looking at the variable names you're using, and then using firefox poster to send whatever string I like to your server to bypass all client side validation. If you aren't validating user input SERVER SIDE then you're doing almost nothing productive to protect from XSS.
Any client side xss protection would have to do with how you render user input; not how you receive it. So, for example, if you encoded all input so it does not render as html. This goes away from what you want to accomplish though (just anchor and img tags). Just keep in mind the more you allow to be rendered the more possible vulnerabilities you expose.
That being said the bulk of your protection should come from the server side and there are a lot of XSS filters out there depending on what you're writing with (ex, asp.net or tomcat/derby/jboss) that you can look into.
I think you're on the right path by allowing ONLY a and img tags. The one thing you have to keep in mind is that you can put javascript commands into the src attributes of a tags, so take care to validate the href attributes. But the basic idea of "allow nothing and then change the filters to only allow certain things" (AKA whitelist filtering) is better than "allow everything and then filter out what I don't want" (AKA blacklist filtering).
In the comments below, Brian Nickel also said this which illustrates the point:
Everything but the elements and attributes you want to keep. I
know you mentioned it in your answer but that bears repeating since it
is so scary. <img onerror="stealMoney()">
The other thing you're going to want to do is define a XSSFilterRequest object (or something along those lines) and in a filter, override your requests so that any call to whatever your "getUrlParameter" and "getRequestParameter" objects run the request values through your xss filter. This provides a clean way to filter everything without rewriting existing code.
EDIT: A python example of xss filtering:
Python HTML sanitizer / scrubber / filter
Python library for XSS filtering?
What about using google caja (a source-to-source translator for securing Javascript-based web content)?
Unless you have xss validation on server side you could apply html_sanitize both to data sent from the user and data received from the server that is to be displayed. In worst case scenario you'll get XSSed content in database that will never be displayed to the user.
I'm xss-proofing my web site for javascript and xss attacks. It's written in ASP.NET Webforms.
The main part I'd like to test is a user control that has a textbox (tinyMCE attached to it).
Users can submit stories to site by writing in this textbox. I had to set validateRequest to false since I want to get users' stories in HMTL (tinyMCE).
How should I prevent javascript-xss attacks? Since users' stories are HMTL texts, I cannot use Server.HtmlEncode on their stories. In general, what's the safe way to receive HTML content from user, save and then display it to users?
If one user puts malicious code in the textbox and submits it, is there a chance that this could harm other people who view that text?
Thanks.
If you don't clean what the user puts in the textbox and submits, then yes, there is a chance for harm to be done.
You might want to check out the Microsoft Anti-Cross Site Scripting Library, as it is designed to help developers prevent just such attacks.
Also worth taking a look at is OWASP's Cross-site Scripting (XSS)
You might want to look into HttpUtility.HtmlEncode and HttpUtility.HtmlDecode as well. I just wrote a quick test, and it looks like it might address your concern in the comment below (about how to display the data to other users in the right format):
string htmlString = "<b>This is a test string</b><script>alert(\"alert!\")</script> and some other text with markup <ol><li>1234235</li></ol>";
string encodedString = HttpUtility.HtmlEncode(htmlString);
// result = <b>This is a test string</b><script>alert("alert!")</script> and some other text with markup <ol><li>1234235</li></ol>
string decodedString = HttpUtility.HtmlDecode(encodedString);
// result = <b>This is a test string</b><script>alert("alert!")</script> and some other text with markup <ol><li>1234235</li></ol>
ASP.NET Controls and HTMLEncode
I was going to post the information I had from my class, but I found a link that lists the exact same thing (for 1.1 and 2.0), so I'll post the link for easier reference. You can probably get more information on a specific control not listed (or 3.0/3.5/4.0 versions if they've changed) by looking on MSDN, but this should serve as a quick start guide for you, at least. Let me know if you need more information and I'll see what I can find.
ASP.NET Controls Default HTML Encoding
Here's a more comprehensive list from one of the MSDN blogs: Which ASP.NET Controls Automatically Encodes?
I would go with storing it encoded in database, then when showing Decode it and replace only the < with < if you say you need to preserve other things.
As far as I know, if you replace the < XSS is not really possible as any JS code must be inside <script> tags to be executed and by replacing, you'll get this in the HTML source:
<script> and the user will see <script> on the screen as the browser will parse the < entity.
This said, if you allow users to post "raw" HTML e.g. <b>this section is bolded</b> then you'll have to create "white list" of allowed tags then manually replace the < with the proper HTML for example:
string[] allowedTags = new string[] { "a", "b", "img" };
foreach (allowedTag in allowedTags)
output = output.Replace("<" + allowedTag, "<" + allowedTag);
Have you seen the OWASP guide on this
The best way would be to have an white list of allowed tags instead of a trying to come up with a way to prevent all script tags.
One solution on how to do this is here How do I filter all HTML tags except a certain whitelist?
But you also need to be aware people might have a link to external script via an image tag with a URL to their own server. See examples here http://ha.ckers.org/xss.html of the different types of attacks you need to defend against