I'm getting Client DOM Open Redirect security issue on scan for the following piece of code.
The issue shows up where I'm initializing the variables 'myPath' and 'myHost'.
I'm not able to understand how is that open to phising attack and how do I fix it.
Could anyone please help?
var query = this.value;
var myPath = window.location.href.substring(window.location.href.indexOf("/myapp"), window.location.href.indexOf(".html"));
var myHost = window.location.href.substring(0, window.location.href.indexOf("/myapp"));
query = encodeURIComponent(query);
if(myPath!==null){
query = query + "mysite:" + myHost + myPath;
}
The problem is that you are taking user input (values from the url bar) and you redirect to it. This may or may not be exploitable in any meaningful attack, but static scanners don't understand your application logic - for a static scanner it's just user input that will directly be used in a redirect.
Based on the info in the question, I can't think of a valid attack, because I think it just makes the same url that the user already visited, without .html in the end, and also without the # part if there was any. So I think the user will be redirected to a page that he visited already. However, that doesn't at all mean there is no vulnerability, and it also depends on other related code. What happens when the user can access a page with this code without any .html in the url bar would for example affect the outcome, so would another vulnerability that allows (partial) control of the url bar, a possible scenario for something like an SPA. So there is not enough info in the question to decide whether it's actually secure or not.
As for the fix, make sure you only redirect where you want to, and not to any user input. For example the host part (maybe even the path) could be written in the page by the server, but I understand that would not be the case for something like an SPA. You could implement whitelist validation to ensure no rogue redirects happen. Maybe it's already good, in which case you can set this finding to mitigated in the scanner you used, but think about edge cases, and how this can be abused by an attacker. Can he trick this with # in the path? Can he load a page with this code from an url that doesn't have .html? Or has it multiple times? What if he registers a domain like someattack.html.hisdomain.com and has a valid user visit it? :)
The url bar is a tricky thing, because it's user input, but the attacker doesn't have full control - he must hit an application page, otherwise this javascript won't be loaded. Still the reason this is flagged by a static scanner is because an attacker may have some control, and in case of javascript-heavy single page applications, probably a bit more because of all the url bar manipulation going on.
Related
Intro:
I am pretty inexperienced, but recently I have been trying to access some data from a website using Google Apps Scripts. However, to access the data, I must be logged into that website. There have actually been many posts about similar issues before, but none of them were very helpful until I came to this one: how to fetch a wordpress admin page using google apps script. The accepted answer gave a method for saving the cookies and sending them out again in the second request. I basically copied and pasted the code into my own GAS file. Since the problem in that post was logging into Wordpress, I tried that first, and it worked. I had to remove the if statement checking for the response code because 200 was being returned even when I entered the correct combo. I don't know if that was just an error in the post's code or what. In any case, I verified that the second request I made returned information as if I was logged in.
Details about specific site:
The actual website that I am trying to log onto has a some kind of weird hashing method that I haven't seen on any other login pages. When you click submit, the password changes to something really long before going to another page. The opening form tag looks like this:
<form action="/guardian/home.html" method="post" name="LoginForm" target="_top" id="LoginForm" onsubmit="doPCASLogin(this);">
As you can see, it has an "onsubmit" attribute, which I believe will just run "doPCASLogin(this);" when the form is submitted. I decided to play around with the page by just entering javascript into the address bar. What I found was that doing a command like this (after entering in my username and password):
javascript: document.forms[0].submit();
didn't work. So I dug around and found the function "doPCASLogin()" in a javascript file called "md5.js". I believe md5 is some kind of hash algorithm, but that doesn't really matter. The important part of "doPCASLogin()" is this:
function doPCASLogin(form) {
var originalpw = form.pw.value;
var b64pw = b64_md5(originalpw);
var hmac_md5pw = hex_hmac_md5(pskey, b64pw)
form.pw.value = hmac_md5pw;
form.dbpw.value = hex_hmac_md5(pskey, originalpw.toLowerCase())
if (form.ldappassword!=null) {
form.ldappassword.value = originalpw;
}
}
There is some other stuff as well, but I found that it didn't matter for my login. It is pretty obvious that this just runs the password through another function a few times using "pskey" (stored in a hidden input, different on each reload) as a key, and puts these in inputs on the original form ("dbpw" and "ldappassword" are hidden inputs, while "pw" is the visible password entry input). After it does this, it submits. I located this other "hex_hmac_md5()" function, which actually connects to a whole bunch of other functions to hash the password. Anyway, that doesn't matter, because I can just call the "hex_hmac_md5()" from the javascript I type in the address bar. This is the working code that I came up with, I just broke the line up for readability:
javascript:
document.forms['LoginForm']['account'].value="username";
document.forms['LoginForm']['pw'].value="hex_hmac_md5(pskey, b64_md5('password');)";
document.forms['LoginForm']['ldappassword'].value="password";
document.forms['LoginForm']['dbpw'].value="hex_hmac_md5(pskey, 'password')";
document.forms['LoginForm'].submit();
Wherever you see "username" or "password", this just means that I entered my username and password in those spots, but obviously I have removed them. When I discovered that this worked, I wrote a small Chrome extension that will automatically log me in when I go to the website (the login process is weird so Chrome doesn't remember my username and password). That was nice, but it wasn't my end goal.
Dilemma:
After discovering all this about the hashing, I tried just putting in all these values into the HTTP payload in my GAS file, though I was skeptical that it would work. It didn't, and I suspect that is because the values are just being read as strings and the javascript is not actually being run. This would make sense, because running the actual javascript would probably be a security issue. However, why would it work in the address bar then? Just as a side note, I am getting a 200 response code back, and it also seems that a cookie is being sent back too, though it may not be valid. When I read the actual response, it is just the login page again.
I also considered trying to replicate the entire function in my own code after seeing this: How to programmatically log into a website?, but since "pskey" is different on each reload, I think the hashing would have to be done with the new key on the second UrlFetch. So even if I did copy all of the functions into my GAS file, I don't think I could successfully log on because I would need to know the "pskey" that will be generated for a particular request BEFORE actually sending the request, which would be impossible. The only way this would work is if I could somehow maintain one page somehow and read it before sending data, but I don't know how I would do this with GAS.
EDIT: I have found another input, named "contextData", which is the same as "pskey" when the page is loaded. However, if I login once and look at the POST request made using Chrome Developers tools, I can copy all the input values, including "contextData", and I can send another request a second time. Using javascript in the address bar, it looks like this:
javascript:
document.forms['LoginForm']['account'].value="username";
document.forms['LoginForm']['pw'].value="value in field that browser sent once";
document.forms['LoginForm']['ldappassword'].value="password";
document.forms['LoginForm'['dbpw'].value="value in field that browser sent once";
document.forms['LoginForm'['contextData'].value="value in field that browser sent once";
document.forms['LoginForm'].submit();
I can sign into the website as many times as I want in this manner, no matter what "pskey" is, because I am submitting everything directly and no hashing is being done. However, this still doesn't work for me, so I'm kind of stuck. I should note that I have checked the other hidden input fields and I can still log in successfully with the javascript above even after clearing every input in the form.
QUESTIONS:
-was I correct in assuming that the code I was sending was being interpreted as a string?
-why is the new code below that I just recently wrote not working?
-for future reference, how would I use GAS to sign into a site like Google where a randomly generated string is sent in the login form, and must be sent back?
function getData() {
var loginURL = 'login page';
var dataURL = 'page with data';
var loginPayload = {
'account':'same as in previous code block',
'pw':"same as in previous code block",
'ldappassword':'same as in previous code block',
'dbpw':"same as in previous code block",
"contextData":"same as in previous code block",
};
var loginOptions = {'method':'post','payload':loginPayload,'followredirects':false};
var loginResponse = UrlFetchApp.fetch(loginURL,loginOptions);
var loginHeaders = loginResponse.getAllHeaders();
var cookie = [loginResponse.getAllHeaders()["Set-Cookie"]];
cookie[0] = cookie[0].split(";")[0];
cookie = cookie.join(";");
var dataHeaders = {'Cookie':cookie};
var dataOptions = {'method':'get','headers':dataHeaders};
var dataResponse = UrlFetchApp.fetch(dataURL,dataOptions);
Logger.log(dataResponse);
}
some kind of weird hashing method that I haven't seen on any other login pages
This login uses the well-known MD5 hashing algorithm from a base-64 encoded password (of note is that it uses the same password, but lowercased, for what seems like database access dbpw and has an option of sending the plaintext (!) version of the password for LDAP login).
know the "pskey" that will be generated for a particular request BEFORE actually sending the request, which would be impossible
pskey simply stores the key used in computing HMAC signature. There is nothing stopping you from hardcoding it, reading from disk, generating it or fetching from remote whenever and wherever you want (obviously, before the computation).
running the actual javascript would probably be a security issue
Although running untrusted JavaScript code is indeed a security issue, this is not what happened at all in your case. See next point for detailed explanation why. What you should've done, is to actually run the hashing functions (in 2020, Utilities service provides everything you need in that regard) before assigning them to loginPayload properties.
was I correct in assuming that the code I was sending was being interpreted as a string?
Everything you put in quotes (single or double) is treated as a sequence of characters. That's not how Google Apps Script works, this is how ECMAScript (on which it is based) is designed to work. In order to execute the functions "inside" the string, you need to use eval, but please never do that.
Now, in 2020 it took me some time to remember what javascript: protocol meant. This is the only reason why your code executed in the first place - you explicitly told the browser that what follows is JavaScript code to be executed. If someone sees this: please, don't use that ever again.
Google Apps Script is a server-side code and is not executed in the browser environment, therefore, even if you did use the protocol, it would have no effect because no evaluation took place.
why is the new code below that I just recently wrote not working?
Because of all the reasons explained above.
for future reference, how would I use GAS to sign into a site like Google where a randomly generated string is sent in the login form, and must be sent back?
If you are talking about the OAuth / OAuth2.0 authentication protocol, here is an officially endorsed library dedicated for exactly this purpose.
Okay so there are solutions for this as in Modify the URL without reloading the page but I have one question regarding this.
So here is what I plan to do (let's assume my web address is example.com)
1. using pushState I plan to change the browser address to example.com/myprofile/myalbum. So to be clear, this new url may or may not exists but the browser address is changed regardless. In our case this url doesn't actually exist but we are using the address to mark a changed state of the webpage.
2. use ajax to load data regarding "myprofile > myalbum" to the same page.
But now here's the issue I have been thinking about. What if a user loads example.com/myprofile/myalbum directly on a, let's say, new tab. This page clearly throws a not found error because it doesn't exist.
So how do I load ajax corresponding to this fake url? For example http://www.usatoday.com/news/ seems to do this well (unless that's an iframe, which wouldn't be so nice).
You can add rewrite rules to your webserver, converting either specific URL's or some matching a pattern to something that your scripts can use to show the right page. You can have it rewrite the URL only internally, so the user still see the original URL in the browser. Such as:
RewriteRule /myprofile/(\w*) /index.php?path=/myprofile/$1
Different webservers will probably have different syntax, but they will be similar.
Some users repeatedly run into a very mysterious problem when using my web application.
In the middle of using it, they'll click a button or link that takes them to another page, but there will be a "page not found" error, because the URL is something like:
http://www.correctwebsitename.com/undefined
I thought it might be a javascript bug in my app: a redirect done by choosing a page name (maybe with some parameters) where one of the values is bad, resulting in the page name = "undefined". But there is no such code in my app anywhere, and this happens on many different pages, seemingly at random.
The one thing that seems to make it happen more often is if the user logged in originally by clicking a link in an email message in gmail. But a user who cut and pasted the link URL into a browser window said it still happened. Googling around reveals some hints that some kind of Google redirecting or caching is happening behind the scenes.
Any ideas?
Edit:
I'm not getting responses from anyone familiar with how gmail links etc work, does anyone know what SO tags google experts "hang around in"?
Edit 2:
Awarding bounty to top answer for useful info and temporary workaround idea, but still interested in real solution to the problem, so not accepting workaround as solution.
I believe you are right about gmail doing something with the links. See the gmail image below:
Non-standard header fields are conventionally marked by prefixing the field name with X-
Its probably behaving like... oh well, Google, and inspecting everything.
To stop google search from tracking my clicks i had to create a userscript to rewrite one of their functions:
rwt = function(){};
Maybe you can try something similar for gmail.
What is rwt?
rwt() is a javascript function from google search that rewrites the links to track which site you have visited.
for example, searching for "greasemonkey" showed the mozilla addons page as the first result. clicking on it opened
https://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCUQFjAA&url=https%3A%2F%2Faddons.mozilla.org%2Fpt-BR%2Ffirefox%2Faddon%2Fgreasemonkey%2F&ei=iWNtUIXjIoyQ8wTxv4DQAQ&usg=AFQjCNEO9EJcHp9rAmKyD_XZF2Bt6hs_YQ&sig2=P19xVUsD-Q1G_9AiUBP3PQ
and then redirected to
https://addons.mozilla.org/pt-BR/firefox/addon/greasemonkey/
The image above and the rwt() case is just to show you that there is a great chance that gmail is changing the links, so this could be related to your problem.
Since there is nothing you can do at gmail's side, maybe you could fix it on your server, by redirecting http://www.correctwebsitename.com/undefined to http://www.correctwebsitename.com or any other page that you'd like your users to see.
So, be it from gmail or any other referer, every time a client lands on http://www.correctwebsitename.com/undefined redirect him to another page.
so maybe I can figure out how to just send them back to the page they
came from
ASP
if not request.UrlReferrer is nothing then
response.redirect (request.UrlReferrer.tostring)
end if
JS (for this to work, you would have to actually create a page called undefined)
if (window.location.href.toLowerCase().indexOf('undefined') > -1) {
// this works
window.location.href = document.referrer;
// this works too (uncomment to enable)
// history.back();
}
remember that if the user directly typed the url or used the link from favorites there wont be no referrer
I would suggest you to check the below things in your application.
Is there any code in your application, apart from what you own ?
there can be injected code by third party applications, like for ex "AddThis" adds an extra #parameter to your url sometimes, in your case its clear that a javascript is trying to playaround with the location.href as "undefined" is something which many js developers will come across.
by adding an # will help do cross site communication, some bug might also be causing an issue here.
Do a complete search in your code for "location.href" and see if you have used it anywhere.
Sometimes third party addons on the browser too might cause this issue
hope these would help you narrow down to your problem.
if you are not able to trace out the issue anywhere, i would suggest you to override 404 functionality on your webserver and implement the solution using Referrer.
Note: The question is not how to fix the problem, as that is documented elsewhere on SO (e.g., Integrating Facebook to the leads to blank pages on some browsers / fb_xd_fragment).
1) What causes this, and under what conditions is it triggered?
2) More importantly, does this affect end users at all? For instance, how does this bug affect the URL shared by someone who clicks the FB Like button? If someone clicks the FB Like button from URL A, does URL A still get shared (but with "fb_xd_fragment" appended), or does URL A become your root URL (with "fb_xd_fragment")? In our logs, all the URLs appear as the root URL with "fb_xd_fragment" appended, so we're not sure if this is because people are clicking the Like button from the home page, or if all the shared URLs get morphed into the root URL.
Basically, what happens is whenever you use the JS API it opens your site in another iframe to use as a cross-domain receiver. What you can do is set a custom channel URL and it will use that instead. If seeing this bothers you, you can set a custom channel url. More information on http://developers.facebook.com/docs/reference/javascript/FB.init/
Is there a way to hide the url in the address bar with Grails application. Now users of the web application can see and change the request parameter values from the address bar and they see the record id in the show page.
Is there a way in Javascript or Groovy (URL Mapping) or Grails (.gsp) or HTML or Tomcat (server.xml or conf.xml or in web.xml inside application in the webapps)
ex(http://www.example.com/hide/show /) i want to avoid this url and always see (http://www.example.com) or (http://www.example.com/hide/show) without the record id
Is there a way to prevent this?
No, most browsers doesn't let you hide the address field, even if you open a new window using window.open. This is a security feature, so that one site can't easily pretend to be another.
Your application should have security checks so that one user can't access data that only another user should see. Just hiding the URL would not be safe anyway, you can easily get around that using tools built into the browser, or readily available addons.
It's part of the restful URL pattern implemented by grails.
Your best bet to hide the URL would be using an iframe within the page you want the user to see in their address bar.
Not quite sure what you mean, but I would change the default root URL mapping in UrlMappings.groovy so it looks a bit like this:
static mappings = {
"/$controller/$action?/$id?"{
constraints {
// apply constraints here
}
}
//Change it here!!!!
"/"(controller: 'controllerName', action: 'actionName')
Where 'actionName' and 'controllerName' are what you want them to be - 'hide', 'show' in your example?
Than pass all parameters via a post instead of a get, just change the <g:form> method.
You will still obviously need to implement any security checking required in the controller as stated by other posters.
Thanks,
Jim.
You can probably handle this using a variation of Post/Redirect/Get:
http://en.wikipedia.org/wiki/Post/Redirect/Get
At our Grails site we have a lot of search fields. When a user clicked a pagination link all those search fields ended up in the URL which created ugly URL:s with a higher risk that users bookmarked those addresses which could mean future problems.
We solved this by saving not only all POST but also GET with parameters into the session, redirect to GET without parameters and append those again in the controller. This not only creates nice URL:s but also a memory so that if a user goes back to an earlier menu, then selected details within that menu are redisplayed.
For your specific request to hide the id in "show/42" you can probably handle that likewise or possibly configure Grails to use "show?id=42" instead, but we don't have that requirement so I haven't looked further into that issue. Good luck!
Forgot to mention: this won't add much to security since links will still contain ids, it will only clean up the address bar.
Here's some sample code that should work. If show?id=42 is called, it saves id=42 in the session, then redirects to just show and id=42 is added to params before further processing. It does what you want, but as commented it might not always be a wise thing to do.
def show = {
if (request.method == 'GET' && !request.queryString) {
if (session[controllerName]) {
params.putAll(session[controllerName])
// Add the typical code for show here...
}
} else {
session[controllerName] = extractParams(params)
redirect(action: 'show')
return
}