Hardening URL's against javascript XSS attacks that use "window.location"

Trying to understand the exposure caused by window.location

used in an .ajax call thusly:

                            window.location = buildTokenUrl('~/editor/', {
                                id: data.contentbankresourceid,
                                assettype: assetType,
                                poolid: self.cachedData().pool,
                                returnUrl: window.location.toString(),
                                defaultStyleId: defaultStyleId,
                                testId: self.testId,
                                formId: $("#formid").val()
                            });

Open in new window


I need some ideas how to block XSS attacks on this kind of code.

One was is for me to possibly expose a new server method that can be used to validate a url, before redirecting.

How might this look? What kind of input params could there be coming from the javascript? How might that server method return a valid URL for that particular case?

Might it choose from a white listed set of URL's?

Thanks
newbiewebSr. Software EngineerAsked:
Who is Participating?
 
Julian HansenCommented:
That's why I am doing a deep dive into the javascript.
You don't sanitize in JS - you do it on the server where it can't be touched - there is no JS action here.

When window.location is set by javascript, can that href value always be hacked by a hacker?
Nothing in the client can be trusted - ever

Are there cases, like when constructing an AJAX call, where instead of inserting a plain text URL, there is a function call that generates the URL? And might that be impossible for a hacker to intercept?
You are looking in the wrong place. If a hacker decides to change the URL and does not hit your page - that is something he is doing on his / her browser - it does not affect other users - so you don't care about him.

With XSS we are concerned that malicious user A types in JS code to a form which is then sent the server and saved but is not sanitized.
Unsuspecting user B then accesses a page that retrieves that code from the database - think of a comments list - the malicious JS from A now fires and changes the browser contents for B tricking them into doing something that compromises their security.

This is what XSS is - it is prevented on the server - not the client.
0
 
Julian HansenCommented:
I am not sure what your intention is?

XSS is an injection attack - you need a form that captures input where that input at some point is sent back to the browser.

Protection against XSS is therefore server side - make sure what you receive from the browser is properly sanitized and make sure what you send to the browser is also.

What is your concern in this case?

Remember that client side JavaScript is modifiable - trying to harden it is a waste of time - focus on the server where the malicious user does not have access.
1
 
Chinmay PatelEnterprise ArchitectCommented:
I think I understand your concern here. I do wonder if your end user manipulates the window.location, wouldn't the page itself will be invalid most probably ending in Page 404? thus your script will never have to be excuted.

In case you are still worried, You can try:
URLencoding on this line

returnUrl: window.location.toString()

Open in new window


and see if it still creates an issue for you.

Regards,
Chinmay.
0
WEBINAR: 10 Easy Ways to Lose a Password

Join us on June 27th at 8 am PDT to learn about the methods that hackers use to lift real, working credentials from even the most security-savvy employees. We'll cover the importance of multi-factor authentication and how these solutions can better protect your business!

 
newbiewebSr. Software EngineerAuthor Commented:
> make sure what you receive from the browser is properly sanitized

That's why I am doing a deep dive into the javascript.

But it sounds like my sole useful take-away would be a list of embedded URL's which are getting pointed at by our web forms.

Then, I simply track down each of those to their C# source locations, and insert my handy URL validation test into each place.

Question:
When window.location is set by javascript, can that href value always be hacked by a hacker?

Are there cases, like when constructing an AJAX call, where instead of inserting a plain text URL, there is a function call that generates the URL? And might that be impossible for a hacker to intercept?

Because, if there is no way to "lock in" a URL from the browser, then no modification in the javascript can bring any reduction in XSS.

Do I understand this right?
0
 
Chinmay PatelEnterprise ArchitectCommented:
Question:
When window.location is set by javascript, can that href value always be hacked by a hacker?

Anything that is on client side, can be manipulated. If you are already using .Net why not use Server side redirection options?
like Response.Redirect and Server.Transfer.

If you can clarify your scenario I think we will have better clarity of possible solutions.
0
 
newbiewebSr. Software EngineerAuthor Commented:
please refresh my memory how these are used?

Response.Redirect and Server.Transfer.
0
 
Chinmay PatelEnterprise ArchitectCommented:
0
 
newbiewebSr. Software EngineerAuthor Commented:
Both URL's are the same.

I am trying to both find exposures while also learning what I should be looking for.

It seems that I can trust my C# redirects if I can be sure to capture any attempt to hack, when the response hits the back-end.

Julian mentioned sanitizing the URL's coming from the browser, and I do have that code completed. I just need to find where a hacker might insert  a bad URL.

So, I presume I need to check the javascript for any place that uses window.location

This would help me find URL's that are supported by our back-end, and would point me to places where I may need to insert URL validation code.

Thanks
0
 
Chinmay PatelEnterprise ArchitectCommented:
Sorry for the duplicate URLs.

Here are the updated one.

Response.Redirect
https://msdn.microsoft.com/en-us/library/a8wa7sdt(v=vs.110).aspx


Server.Transfer
https://msdn.microsoft.com/en-us/library/caxa892w(v=vs.110).aspx
0
 
newbiewebSr. Software EngineerAuthor Commented:
thanks
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.