I am trying to understand what risk Fortify is seeing here. I am new to XSS work and I want to be sure before I decide this isn't a real issue. I can't see how a person could use this code for anything but messing up their own computer, so I am curious if I am missing something.
Here is the source text
Fortify says that the line where window.location.href is being assigned is the vulnerability. "Unvalidated" data sent to browser.
<c:if test="${isExternalUser}">
<script type="text/javascript">
$(function(){
$('#logoutLink').on('click', function(){
var logoutUrl = window.appSettings.context + '/external/logout/';
$.get(logoutUrl).done(function(){
window.location.href = window.location.protocol + "//" + window.location.host + window.appSettings.context + "/?${ssw:encodeJS(header['policy-signout'])}";
});
});
});
</script>
</c:if>
As far as I can tell there is no risk here.
I can't see any risk.
The only unvalidated data external to the browser is
${ssw:encodeJS(header['policy-signout'])}
which is correctly being JS encoded. Maybe Fortify isn't picking up on this fact.
You could try splitting that line (as a test) just to make sure it is the encodejs that is not being recognised as executing JS encoding.
var policySignout = "${ssw:encodeJS(header['policy-signout'])}";
window.location.href = window.location.protocol + "//" + window.location.host + window.appSettings.context + "/?" + policySignout;
Related
I am new to javascript, and stuck on this problem. I am trying to have the url query string change based on which checkbox checked. But I seem to have some issue with window.location, Some of the JavaScript is below
var urltest= window.location.pathname;
var urltest2 = window.location.host;
var currentURL = urltest2 + urltest;
url = currentURL + "?" + arr_opts.join('&');
document.getElementById('myurl').innerHTML = url;
//window.location.href = url;
window.location = url;
The window.location does not work here, but when I change var currentURL to
var currentURLL = window.location.href;
it is work, but not with
var urltest= window.location.pathname;
var urltest2 = window.location.host;
var currentURL = urltest2 + urltest;
I need window.location to point page to the currentURL above.
Any help would be appreciated.
You're not providing a protocol, so the location.href change is being treated as "go to this relative path from the current location", i.e. on this page
window.location = window.location.host + window.location.pathname;
// takes us to
// http://stackoverflow.com/questions/35254564/javascript-window-location-not-working/stackoverflow.com/questions/35254564/javascript-window-location-not-working/35254601
Do one of the following
Provide a protocol so it knows it is an absolute URI,
window.location = window.location.prototcol + '//' + window.location.host + window.location.pathname + '?foo=bar';
Tell it to re-use the current protocol but work as an absolute URI
window.location = '//' + window.location.host + window.location.pathname + '?foo=bar';
Provide an origin (instead of host)
window.location = window.location.origin + window.location.pathname + '?foo=bar';
Tell it to re-use the same origin but work as an absolute path
window.location = window.location.pathname + '?foo=bar';
Just update the query
window.location = '?foo=bar';
Always choose the most simple option to make your life easier if you ever need to debug, i.e. if you can assume you will always want the same protocol, host and path, just update the query.
Useful knowledge
Starting a URL with..
// means same protocol
/ means same origin
? means same path
# means same query (will not re-load)
The pathname is going to be something like /questions/35254564/javascript-window-location-not-working, and the host is something like stackoverflow.com. If you put those together with code like yours, you get
stackoverflow.com/questions/35254564/javascript-window-location-not-working
That's clearly not correct; the host looks like part of the pathname. You can use protocol and port if you really feel the need to reconstruct the URL from its constituent parts, but using the href seems simpler if all you want to do is add a query string.
I am using the below javascript code to open the LinkedIn url with some french content.
var link = 'http://www.linkedin.com/shareArticle?mini=true&url=' + url + '&title=' + title + '&summary=' + summary + '&source=testing';
window.open(link, 'share_it', 'width=520,height=570');
But its working fine in chrome with below french contents but not working in IE 11. Its giving the 404 bad request error.
http://www.linkedin.com/shareArticle?mini=true&url=http://testing/&title=PageTitle&summary=énergétique&source=testing
EDIT:
I have tried with encodeURI it opening the window but after logged in the summary is not getting displayed the title only getting displayed. What to do on this one.
Can anyone tell me what i have done wrong.?
I just tried to use it on IE10. The issue is because of the characters in the french language that you must encode. To solve the issue simply use encodeURI() function and you won't get the Bad Request error.
var link = 'http://www.linkedin.com/shareArticle?mini=true&url=' + url + '&title=' + title + '&summary=' + summary + '&source=testing';
link = encodeURI(link);
window.open(link, 'share_it', 'width=520,height=570');
I tested it, and it was working fine for me on IE10 as well.
I'm using javascript to get base url using this code:
alert(window.location.protocol + "//" + window.location.host);
It will display http://localhost:[port_number] in development site. Then, after deploy to production site, it will display http://dev01
It gives me wrong base url, since the home url is http://dev01/WebApplication1. I can add the application name in the code, so it will be:
alert(window.location.protocol + "//" + window.location.host + "/WebApplication1");
but this method is not practical, because I have to remove "/WebApplication1" when in development site.
Is there any workaround for this case?
Can you simply add some conditional logic to append the subdirectory in production?
var host = window.location.host,
path = host === 'dev01' ? '/WebApplication1' : '',
fullPath = window.location.protocol + '//' + host + path;
alert(fullPath);
You need to do this from server side.
The WebApplication1 will change depends on your IIS virtual directory setting
To have the code working for both Development & Production environemnt
Try the following.
in Layout.cshtml
<head>
<script>
var base_url = '#Request.Url.GetComponents(UriComponents.SchemeAndServer, UriFormat.Unescaped)#Request.ApplicationPath'
// navigate around the site, base url should be the same
alert(base_url);
</script>
</head>
Try following code it may work:
var patharray=window.location.pathname.split("/");
alert(window.location.origin+"/"+patharray[1]);
Here window.location.path will give you full path of your site...
What I want is do this:
var siteBaseUrl = window.location.origin;
But in IE 9 it's returning undefined
Trying to understand how do I use modernizr from the suggestion here:
$window.location.origin gives wrong value when using IE
I updated my code to add this block before my siteurl:
if (!window.location.origin) {
window.location.origin = window.location.protocol + "//" + window.location.hostname + (window.location.port ? ':' + window.location.port : '');
}
var siteBaseUrl = window.location.origin;
So now the above works, but I am not sure if modernizr suggestion in the link above can help me do it differently.
Or may be I am confusing myself and the above code is working due to modernizr.
All modernizr will do in this case is tell you that the method is missing. Since it does not fix/polyfill anything itself, you would have to do the same work.
There would be no difference.
I want to set a page's base href attribute in Javascript based off of the current hostname. I have generated HTML pages that can be viewed on different hostnames, which means generating a base href tag will work in one hostname but will be incorrect in the other.
The correct way of doing this is to do a document.write of the tag based off the current hostname:
Correct:
<script type="text/javascript">
document.write("<base href='http://" + document.location.host + "' />");
</script>
This method has produced correct results in IE, FF, Chrome, and Safari. It produces a (correct) different result than doing the following:
Incorrect:
<script type="text/javascript">
var newBase = document.createElement("base");
newBase.setAttribute("href", document.location.hostname);
document.getElementsByTagName("head")[0].appendChild(newBase);
</script>
I think you'd better do it this way
<script type="text/javascript">
document.head.innerHTML = document.head.innerHTML + "<base href='" + document.location.href + "' />";
</script>
As location.hostname does not return the application context root! You could also log the document.location on the console console.log to see all available metadata on document.location.
I have to disagree with the top answer. It does not account for the protocol so it will fail.
A working solution that I have to account for protocol / host / port is the following
var base = document.createElement('base');
base.href = window.location.protocol + '//' + window.location.hostname + (window.location.port ? ':' + window.location.port : '');
document.getElementsByTagName('head')[0].appendChild(base);
This currently works fine in all major browsers including IE11
I have used this to make an npm package that also supports adding a suffix to the end of this base href if anyone is interested
https://www.npmjs.com/package/dynamic-base
https://github.com/codymikol/dynamic-base
document.write("");
<script>
document.write("<base href='"+ window.location.protocol +'//' + window.location.host + "' >");
</script>