Let's say I have a <textarea> and <div> element, and when the user puts html, CSS, or whatever they want), into the textarea, then their input is set as the innerHTML of the <div> element, using javascript.
What are the vulnerabilities of letting the user define the content of a <div> element?
If the content they enter does not leave the page, there is no more risk than them editing the DOM through firebug or the chrome inspector. If you take their input and then display it as is, that is a huge security risk especially when other users are on your website.
Well if you encode the contents so that any javascript that is in there won't execute then it should be safe.
If you don't then a user could upload javascript that would execute the next time another user views that page.
I want to modify my response to take into account #Brigham comments. Escape only works reliably if you are dealing with the the innerHTML of something like a div tab, if you are dealing with using a user generated value as a attribute or within a script tag then escaping/encoding won't work.
I'll refer you to the OWASP XSS guidance (that #Brigham originally brought to my attention) for more information: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#Untrusted_Data
The user can do cross-site scripting. It can inject malicious client-side code
Take a look at http://en.wikipedia.org/wiki/Cross-site_scripting
Whatever they want could include a <script> tag which pulls a .js file from their own server. Then if you show that content to another user, the script could do all kinds of things to extract information from the unsuspecting user.
Related
I'm trying to implement an XSS attack by injecting javascript into a page that runs when a button on the target page is clicked. How can I link the script from my html file to the button on the target page? I'm tried just mimicking the button element on my html page with an onclick attribute but that doesn't work. I tried using an iframe to clickjack but I couldn't get that figured out either. This is for a school assignment so I'm not ACTUALLY hacking a legit website by the way.
XSS is when user input is inserted directly into the DOM without escaping, allowing an attacker to craft a malicious payload that your script will run and inject into the page.
A good example would be a script that reads an error message from a query parameter, and uses .innerHTML to display it on the page.
http://insecure.website.com/example?error=Something+went+wrong
But when used by an attacker like so:
https://www.website.com/example?error=%3Cspan%20class=%22haha%22%3EPWND%3C/span%3E%3Cstyle%3E*{display:none%20!important;}.haha{display:block%20!important;}%3C/style%3E
Would cause a "PWND" message to appear.
This is a school assignment, so I won't give you a complete solution. But this should push you in the right direction.
I am working on page, which uses a modal dialog to allow a customer to chose an item.
On this dialog, the customer can choose one item from a pre-populated list or write in their own item. Once the user clicks the OK button, the modal goes away, gets the name of the item using .val() and through jQuery's .text() function we enter whatever the item name was into a div element.
Since the customer can write in anything, do I have to be concerned about them putting in a <script></script> tag? Are there any other security things I should be concerned about in this scenario?
I am not worried about the back end as when the user finally submits this form, we have input validation on the back end. I am just concerned about the front end.
Thanks!
If you use jQuery's .text(untrustedString) method, you'll be fine. That method will escape any html or tags.
$('<div>').text("<test>")[0].innerHTML
// returns "<test>"
What you would not want to is use .html(untrustedString) method, as any script tags or other html elements in the string would get created.
$('<div>').html("<test>")[0].innerHTML
// returns "<test></test>"
Although, if this will only be shown in their own browser there isn't much security to be gained. You would only be able to attack... yourself? People already have the ability to inject whatever javascript they want into a webpage running in their own browser, should they desire.
The only time this matters to security is if my hacking script tag executed in someone elses browser, which, for instance, beams their cookie to me over the internet and I can assume their identity on your website.
So this isn't about security, it's about your app not exploding when someone enters text that may have meaning to HTML.
That said, in this case, you should definitely use text().
I have a HTML Page, in which there are some hidden DIVs and these DIVs are visible vai view source of a page. These DIVs should not be visible to a user when they "view source" of the page.
How this can be done ? Perhaps Javascript or other solution?
You can't really prevent a div from being read, because if you do, there will be no render of it.
It can be encrypted and generated via javascript. But once it is generated, user will be able to see it clearly in computed source.
There is no way of doing what you want. The source (in case of HTML) is just text containing HTML markup. The show source view in the browser shows it to you as it came from the server with added syntax highlighting, but unlike the developer tools, it doesn't reflect any DOM changes done with Javascript. Even if some browser had a feature to prevent some parts of the source from being displayed, users will still be able to open it in another browser or download the HTML as a file and examine the source in a text editor.
JavaScript will only change the "computed source" so the client will still be able to see them. In order to really remove them you'll need to remove them server side.
You can not really hide the source code but you can encrypt it. What you transmit from Server to the Client will be in the client side browser and can be seen somehow.
With a tool like the one I just googled http://www.iwebtool.com/html_encrypter it is possible to encrypt html.
It will encrypt your html code and you can insert it via javascript later. Encryption will not finally hide it from someone keen in using debugging tools. But a "normal" user won't see it directly in the source.
Still you should be thinking about storing information you want to hide from the user server-side in a session or something.
Input fields are usually associated to forms, but I would like to use them in a simple Javascript/HTML page. I don't need the form. I see no issue with my HTML page, but is there any danger or bad practice I am not aware of? I just don't want my page to bug down the road.
(Basically, a field in my page can be Javascript enabled or disabled according to values in other fields)
The only real problem is if you want your page to function for users who have JavaScript disabled - if the inputs are actually for user input then placing them outside a form means that you'd need to use JavaScript (presumably with Ajax) to do anything with the values, whereas form fields can be submitted without JavaScript. If your page isn't intended to be submitted to the server anyway then you're dependent on JavaScript for interaction. If you've taken that into account and it doesn't matter for your scenario then go ahead.
P.S. I should've mentioned that as far as HTML standards go it is perfectly valid to have input elements that aren't in forms.
You should be fine AFAIK. It's ok in the HTML 4.01 standards anyway
http://www.w3.org/TR/html401/interact/forms.html#form-controls
The elements used to create controls generally appear inside a FORM
element, but may also appear outside of a FORM element declaration
when they are used to build user interfaces. This is discussed in the
section on intrinsic events. Note that controls outside a form cannot
be successful controls.
You can use an HTML validator (here, or on many other sites) to check this sort of thing. If it shows up legal, which I think it should in this case, as Ted pointed out, then you are probably good.
In Google Reader, you can use a bookmarklet to "note" a page you're visiting. When you press the bookmarklet, a little Google form is displayed on top of the current page. In the form you can enter a description, etc. When you press Submit, the form submits itself without leaving the page, and then the form disappears. All in all, a very smooth experience.
I obviously tried to take a look at how it's done, but the most interesting parts are minified and unreadable. So...
Any ideas on how to implement something like this (on the browser side)? What issues are there? Existing blog posts describing this?
Aupajo has it right. I will, however, point you towards a bookmarklet framework I worked up for our site (www.iminta.com).
The bookmarklet itself reads as follows:
javascript:void((function(){
var e=document.createElement('script');
e.setAttribute('type','text/javascript');
e.setAttribute('src','http://www.iminta.com/javascripts/new_bookmarklet.js?noCache='+new%20Date().getTime());
document.body.appendChild(e)
})())
This just injects a new script into the document that includes this file:
http://www.iminta.com/javascripts/new_bookmarklet.js
It's important to note that the bookmarklet creates an iframe, positions it, and adds events to the document to allow the user to do things like hit escape (to close the window) or to scroll (so it stays visible). It also hides elements that don't play well with z-positioning (flash, for example). Finally, it facilitates communicating across to the javascript that is running within the iframe. In this way, you can have a close button in the iframe that tells the parent document to remove the iframe. This kind of cross-domain stuff is a bit hacky, but it's the only way (I've seen) to do it.
Not for the feint of heart; if you're not good at JavaScript, prepare to struggle.
At it's very basic level it will be using createElement to create the elements to insert into the page and appendChild or insertBefore to insert them into the page.
You can use a simple bookmarklet to add a <script> tag which loads an external JavaScript file that can push the necessary elements to the DOM and present a modal window to the user. The form is submitted via an AJAX request, it's processed server-side, and returns with success or a list of errors the user needs to correct.
So the bookmarklet would look like:
javascript:code-to-add-script-tag-and-init-the-script;
The external script would include:
The ability to add an element to the DOM
The ability to update innerHTML of that element to be the markup you want to display for the user
Handling for the AJAX form processing
The window effect can be achieved with CSS positioning.
As for one complete resource for this specific task, you'd be pretty lucky to find anything. But have a look at the smaller, individual parts and you'll find plenty of resources. Have a look around for information on modal windows, adding elements to the DOM, and AJAX processing.