1

I have a page on my website like this : domain.com?img=test.jpeg And on the page, the javascript written is:

var imgPath = getQuerystring('img');
$("#img").attr('src','/Images/' + imgPath);

I was wondering if someone can manipulate the querystring to do something mailicious.

Since the javascript is always appending the path with '/Images/', I hope its not vulnerable.

But then I changed my js code to this:

$("#img").attr('src',imgPath);

Now when I passed a malicious querystring like this:

domain.com?img=alert('XSS')

But whoops, it didnt show me the alert box.

Is this kind of attack taken care of by our Web browsers?

1

XSS isn't just about making alert boxes appear and redirecting to other pages, there are other things it can do. ;)

What are you doing with the input that the user specifies? Does this get stored in a database, or is it used to retrieve images?

The input that you are taking in, does it get redisplayed anywhere on your site? If so there could be a persistent XSS issue, as you have stored the input that an untrusted user has given to you.

Best answer is to make sure you strip any special characters from that field before using it elsewhere in your application, as this nullifies the XSS risk.

  • thanks for the answer but that is not the point.. xss is surely not about making alert boxes appear..but being a newbie i was just trying to make it run a js code.. – Lakshay Jul 3 '14 at 13:04
  • I wasn't getting at you by saying that, I was trying to point out that all you've tested is making an alert box appear. How about testing navigating through your directory structure? My point is that if you're going to accept untrusted user input, you never know what people may try, so trying one particular scenario proves nothing. The easiest, most secure thing to do is to ensure that nothing could be inserted there which can then be interpreted as code. – TimC Jul 3 '14 at 13:15
  • I agree on that Tim :) – Lakshay Jul 3 '14 at 13:18
0

If you use

$("#img").attr('src', imgPath);

i believe

http://example.com/?image=javascript:alert("Hi");

would work.

However, as you said, the prepended /Images/ should at least kill all Javascript. Still, it is possible to display any image accessible through your websever (and by that meaning any php-scripts etc) as $("#img"), e.g.:

http://example.com/?image=../css/images/some_background.png
  • i guess i tried 'javascript:alert' also, but it didnt fire up an alert box.. i will try it again.. so basically you are saying that my code is not vulnerable :) considering there are no php scripts since it is a .net code.. – Lakshay Jul 3 '14 at 13:07
  • This would end in /Images/javascript:alert("Hi");. – Gumbo Jul 3 '14 at 13:44
  • No, i put a condition to the use of javascript:: If he used $("#img").attr('src', imgPath); a javascript: could work. But since the TO is prepending a /Image/ all JS-Syntax is rendered invalid. @Lakshay: .NET code is as vulnerable. Say you have a .NET function in your site that will load an image from a protected area of your Applications-Webspace or from another server, i could display any image i wanted like this: http://example.com/?image=../some_script.asp?url=http://attackerdomain.com/image.png – marstato Jul 3 '14 at 13:47
  • When we are talking about client-sided javascript, then directory traversal is usually harmless, because it can't be used to access a file the client couldn't access anyway. The request for the file comes from the client, so any non-public files on the server (like PHP scripts or .NET assemblies) are save. – Philipp Jul 3 '14 at 13:52
  • @marstato ok so this can only show a different image..can it do anything more malicious? – Lakshay Jul 3 '14 at 13:53
0

Doing this $("#img").attr('src',imgPath); is very bad. You allow an attacker to execute arbitrary javascript with your user's credentials. But even if you block javascript and allow only url's the attacker can craft links which will allow him to execute a get request on any arbitrary url on behalf of your users. When the browser renders an node it gets the value in the src attribute and makes an HTTP GET request to that address. In your case that address is controlled by the attacker who can craft a link with any url.

Regarding the second option$("#img").attr('src','/Images/' + imgPath); I haven't thought of a direct way to load javascript or any resources outside of your domain. But it is still dangerous and could be exploited since you are allowing the attacker to craft a link which will make the user perform a GET request to any resource on your domain. For example if your web site has an API, you will allow the attacker to be able to make an API GET request on behalf of the user, these should be harmless (read only) if you followed the correct security suggestions, but still might brake your logic in the worst case.

My suggestion is to find a way to overcome this with a different architecture. Why not accept an ID of an image and render it into a url in the server side if its legal? You could also do that in javascript if you dont want to do it on server side. The idea is to accept a value that cannot be controlled and affect the final url.

  • I understand the http get request part. But I dont think with "/Images/" prepended, the attacker can make any other request work.. Can it? – Lakshay Jul 3 '14 at 14:07
  • sure. lets say you have the api located at /api the attacker can craft the following: img=../api/someaction – aviv Jul 3 '14 at 14:13
  • no I was asking when the code prepends '/Images/' to the querystring – Lakshay Jul 3 '14 at 14:38
  • me too. take a good look at the input – aviv Jul 4 '14 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.