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.
Related
I want to make a page with a lot of Javascript interactions. However, while a user navigates through the page the URL must change too. So, when the user shares the URL or saves it, it can lead him to the actual state he was.
How can I do that?
Examples:
myapp.com/page1
myapp.com/page2
pushState, as seen on github
Answered by this SO question: Change the URL in the browser without loading the new page using JavaScript
The only part of the url (or location) that you can change without reloading the page, is the hash. That is the part behind the #. Many ajax enhanced applications make use of this, including Twitter. You can change this hash on the go, and interpret the hash tag on page load to initialize the page to the correct state.
Set this value: window.location.href
window.location.href = "myapp.com/page2";
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.
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.
I am working on an AJAX website where there are two search parameters. I did some mod-rewrite and checking for $_GET variables so that i can do something like..
site.com/var1/var2/ -> automatically do the search based on the parameters.
Now what I want is for people who do the search manually, to be able to have the url in that format. The only method that I've been able to find has to do w/modifying the url using..
location.hash = 'foo';
which would make it something like.. site.com/#var1
Which isn't as nice as the mod-rewrite. What I have found that works is if in my search function that does the ajax call i have this code
// avoid appending further variables if there are already variables
if(location.href == 'some absolute website path')
location.href = var1+'/'+var2+'/';
This will work, but basically forces the page load and then my auto search php/javascript will kick in due to the mod-rewrite. SO this works, however it involves an extra page refresh that I would rather avoid.
Any better solutions out there? Ideally if i was able to use location.href where it didn't cause the page to load once i change the value, but would just change in the url would be ideal (while maintaining my mod-rewrite links, w/out the # marks).
I am using jquery and php.
It's that way by design, there is no way yo change the url or path without causing a new request. Regards.
I've coded an HTML page using jQuery for loading content. Now if I want to link directly to a submenu, is this possible to do with JavaScript?
So for example if someone goes to www.mydomain.com/submenu1/
then some JavaScript code will execute and load the needed contents?
Thanks a lot :)
Is it possible to realize that with htaccess?
You will more likely want to have a URL structure that only needs a page to load from the server once, then the server is only queried by JavaScript XMLHttpRequests. Loading content based on a "hard" URL would be pointless, since you're doing a server request anyways and might as well return the content in the response.
For keeping addresses unique while still keeping the "hard" URL the same (preventing multiple server requests), you can use the hash/anchor part of the URL. This means your address might look something like this: http://www.example.com/#/submenu1/
The #/submenu1/ part stays on the client, so only / on www.example.com is requested. Then it's up to your JavaScript to load the content relevant to /submenu1/. See a page of mine for an example of this: http://blixt.org/js#project/hash?view=code
Also have a look at this question: Keeping history of hash/anchor changes in JavaScript