Re: The Dangers of Allowing Users to Post Images
Interestingly enough, I don't know if it's because it handles links differently or what, but lynx doesn't treat these as clickable links. Normally when encountering a mailto link it allows you to click on it to email. Because this is imbedded in an src tag though probably makes it ignore it. All I get on the screen is a couple hundred crash words and that's it. :) Guess there is something to be said for text-based browsers after all.
Re: The Dangers of Allowing Users to Post Images
On Tue, 19 Jun 2001, John Percival wrote: I'm going to try and throw another issue into this discussion now too: denial of service. We have discussed it for attacking remote servers, but not for the client viewing the image. It's something else that I spotted while I was playing around with this issue just now. If you have images that include a mailto:[EMAIL PROTECTED] source, then the default handler for mailto: links is opened up. Be that Outlook, Netscape Composer, Eudora, or whatever else you care to use. So if someone embedded 100 (arbitrary figure) mailto: images in a page, then this would do a lot of harm to the user's computer. At best, it would get very busy for a few minutes creating new emails, and would be a pain to clear up. At worst, it could bring the whole system crashing down. This is a user agent problem. Since the mailto scheme can't be used to fetch an image, script, style sheet, object, or anything else, mailto URIs should be ignored in the img, object, link, script, and other elements. I just checked Mozilla and it ignores them. HTML is loaded with these kinds of hazards. img src=file:///dev/zero, microsoft's con\con problems, etc. Careful user agent design is required. -jwb
Re: The Dangers of Allowing Users to Post Images
John Percival wrote: I'm going to try and throw another issue into this discussion now too: denial of service. We have discussed it for attacking remote servers, but not for the client viewing the image. It's something else that I spotted while I was playing around with this issue just now. If you have images that include a mailto:[EMAIL PROTECTED] source, then the default handler for mailto: links is opened up. Be that Outlook, Netscape Composer, Eudora, or whatever else you care to use. So if someone embedded 100 (arbitrary figure) mailto: images in a page, then this would do a lot of harm to the user's computer. At best, it would get very busy for a few minutes creating new emails, and would be a pain to clear up. At worst, it could bring the whole system crashing down. Netscape 4.77 crashes at about 50 such IMG tags, IF they are different (simply putting mailto:fakeluser@fakedomain 100 times won't work (opens only 2 message windows)), but if you go with some script... instant crash (try it now free of charge at http://msz.pmp.com.pl/boom/ ;-)). -- I'm an ugly boy| Nie wchodzic na http://msz.pmp.com.pl/ My face makes you hurl | REKLAMY: I'm a relation |Dla snobow: http://www.filharmonia.pl/ To Frankenstein's creation | Wypij za mnie: http://www.fws.pl/
Re: [BUGTRAQ] Re: never-ending Referer arguments (The Dangers of Allowing Users to Post Images)
On Tue, 19 Jun 2001, Peter W wrote: On Tue, Jun 19, 2001 at 03:44:10PM +0200, Henrik Nordstrom wrote: [EMAIL PROTECTED] wrote: Folks are missing the point on the Referer check that I suggested. I intentionally selected to not go down that path in my message as there are quite a bit of pitfalls with Referer, and it can easily be misunderstood allowing the application designer falsely think they have done a secure design using Referer. Henrik, You also revealed your lack of understanding the Referer check logic when Snide commentary aside, there seems to be a misunderstanding about Referers and their use in any type of validation or check. Let me see if I can make this as clear as possible: Using the referer for anything other than statistics gathering to show the marketing wonks who is linking to your site would be, and is, a mistake. Whether the referer exists or not, is correct or not, or is even the correct format for a URI should be completely irrelevant. If the referer is relevant in -any- way to the integrity of the data you are attempting to validate then your security model is broken. All this chatter about Referer checks amounts to two things: - some folks not understanding the model I understand your model perfectly well and I see it for the fallacy that it is. That you apparently cannot see this for yourself is distressing. I do not see the logic in validating user submitted (form) data with yet more user submitted data. Perhaps I'm misunderstanding why you (or anyone for that matter) would blindly put any credibility what-so-ever in any user input, which includes the Referer. Your three-stage security model has but 1 stage that I can see. The other two steps are sugar coating that add no further benefit to your security model. From one of your previous emails... An attacker can trick the victim's browser into sending 1 + 2. Or the attacker himself can send 2 + 3. But the attacker cannot get the victim to send 1 + 2 + 3, unless the application is poorly designed. By definition an exploitable web application is poorly designed. I can and I have written exploits to re-produce not only valid input, but valid cookies and referer data all in the same instant. The victim didn't even need to click a link - they just opened their webmail and the application was instantly compromised - I had their cookies, the URL data and the referer all rolled into one. The webmail was compromised because my exploit successfully reproduced all three of your security stages. Every single crack out there - from brute forcing passwords to overruning buffers is dependant upon one thing: Improper validation of user supplied or manipulated data. If you decide to treat the Referer as anything other than what it is, untrustworthy user data, you do so at your peril. - folks legitiately disagreeing on the number of user who might be locked out by a Referer check. Those that check the referer for purposes beyond statistical or marketing needs are just wasting time. It can not and will not make the data any safer or more trustworthy. CDI The Web Master's Net http://www.thewebmasters.net/ I would imagine even a trained MSCE-monkey can run a virus scan... OW! What the hell? Ack! Help! Idealism is biting me on the ass! Get it off! Get it off! -- Andrew Boring in the Monastery
Re: The Dangers of Allowing Users to Post Images
I'm going to try and throw another issue into this discussion now too: denial of service. We have discussed it for attacking remote servers, but not for the client viewing the image. It's something else that I spotted while I was playing around with this issue just now. If you have images that include a mailto:[EMAIL PROTECTED] source, then the default handler for mailto: links is opened up. Be that Outlook, Netscape Composer, Eudora, or whatever else you care to use. So if someone embedded 100 (arbitrary figure) mailto: images in a page, then this would do a lot of harm to the user's computer. At best, it would get very busy for a few minutes creating new emails, and would be a pain to clear up. At worst, it could bring the whole system crashing down. So there's something else that needs to be checked in webmail clients in incoming mail, or user submitted content on forums, guestbooks, etc. Blocking mailto: in image tags seems like the best solution for us at vBulletin, so that is probably what we will do. In most general cases, only allowing mailto: in a href=... tags seems like the best solution, or at least not allowing it in images, iframes, embed, object, javascript, etc, etc. I have a feeling that accessing news: or nntp:// might have a similar undesirable effect, but I have not tested this. Finally, another problem that we had to address a while ago in vBulletin was the use of the about: 'handler' in Internet Explorer. Try viewing this URL from your faviourite version of IE (tested on 6.0 beta) about:headtitleHi/title/headbodypHello/p/body This allows anyone to insert their very own HTML, unchecked for nasties, javascript, or anything else, directly into the client's browser. Note that it may need to be 'url encoded' according to RFC1738. This will work for an a tag, and I guess that if would probably work for an iframe. In vBulletin, we test against that by adding a space between about and the colon, which effectively disables any problems. A few that I did test within images in Internet Explorer 6.0, but did not come out with anything useful, are: http://wwp.icq.com/scripts/search.dll?to=42892594 aim:goim?screenname=jhpercivalmessage=Hi.+Are+you+there? telnet:[EMAIL PROTECTED] Anyway, a few more things to discuss and chew over there! Regards, John Percival Product Manager, vBulletin http://www.vbulletin.com/ mailto:[EMAIL PROTECTED] vBulletin: Community Instantly
[Fwd: Re: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)]
Regarding IMG tags in HTML email, here is a good point I received off-list. The sender did not wish to post directly, but approved forwarding this note. -Peter - Forwarded message (anonymous, forwarded with permission) - Date: Sat, 16 Jun 2001 22:55:41 +0200 To: Peter W [EMAIL PROTECTED] From: anonymous Subject: Re: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images) On 2001-06-15 at 09:26 -0400, Peter W gifted us with: I wonder how it would work in HTML mail clients, though? You could restrict to the sender's domain, but email is the easiest thing in the world to spoof. (And an effective attack vector, especially against things like messageboards that expose email addresses.) HTML email is just evil evil evil. I can't see much need for HTML email to reference *any* external documents, or to allow, as Jay Beale suggested, the use of things like META refresh tags to effect client-pull CSRF attacks. Personally, I loath HTML email. However, surely a better approach for this is simply to restrict IMG links by insisting that the source be inline to the email. RFC 2112, multipart/related. Require that email IMG URLs start cid:; in order to be automatically rendered. Whether or not to _allow_ the rendering of other IMGs is a more contentious issue. (Just one of those ideas which I've had floating around for a while, mainly to stop tracking of who's reading spam HTML email) - End forwarded message -
Re: The Dangers of Allowing Users to Post Images
(First, thanks a _lot_ for Squid, Henrik!) [Henrik Nordstrom] | Further, if you pass around the ticket in URLs then this class of | attacks will also have full access to the ticket from the referer | URL, so if you only base your security on these two measurements | (client IP + ticket present in the URL) then your are most likely | at risk here. There are, of course, no reason to add a ticket to off-site links. The tickets are only understandable by our web application. Tickets should only be tied to actions that have side effects on our server (for which GET may be Wrong Thing anyway). If this principle is followed, I can't see how anyone would be able to pick up Referers containing tickets without having access to our server. Please enlighten me if I've misunderstood anything here. Sverre. -- URL:mailto:[EMAIL PROTECTED] URL:http://shh.thathost.com/
Re: The Dangers of Allowing Users to Post Images
Sverre H. Huseby wrote: There are, of course, no reason to add a ticket to off-site links. The tickets are only understandable by our web application. Tickets should only be tied to actions that have side effects on our server (for which GET may be Wrong Thing anyway). If this principle is followed, I can't see how anyone would be able to pick up Referers containing tickets without having access to our server. Please enlighten me if I've misunderstood anything here. If the your page for some reasons references an external object (page, image or whatever) then this external object will get the refeferer header indicating the full URL of your page. If this URL (the URL of your page) includes the users ticket then the ticket is exposed to that external object. From this simple reason, my the guideline is to never include tickets in URL's. Always pass them around using (hidden) form fields sent via POST. -- Henrik Nordstrom Squid HTTP proxy developer
Re: never-ending Referer arguments (The Dangers of Allowing Users to Post Images)
On Tue, Jun 19, 2001 at 03:44:10PM +0200, Henrik Nordstrom wrote: [EMAIL PROTECTED] wrote: Folks are missing the point on the Referer check that I suggested. I intentionally selected to not go down that path in my message as there are quite a bit of pitfalls with Referer, and it can easily be misunderstood allowing the application designer falsely think they have done a secure design using Referer. Henrik, You also revealed your lack of understanding the Referer check logic when you wrote It is well known that Referer can be forged, and to further add to this some browsers preserve Referer when following redirects, allowing this kind of attacks to bypass any Referer check if your users follows URL's (direct or indirect via images) posted by other users or even your own staff when linking to external sites. Neither forging Referers nor preserving Referers across redirects threatens the model I suggested. Also, as shown earlier in the thread, using Referer may render the service less useful for some people. There are people who filter out Referer from their HTTP traffic becuase there is too many bugs in user-agents showing Referer to things it should not expose externally. I mentioned that myself, as you may recall. As for recommending one-time tickets, we agree there. All this chatter about Referer checks amounts to two things: - some folks not understanding the model - folks legitiately disagreeing on the number of user who might be locked out by a Referer check. -Peter Web applications designer and Squid user :-)
Re: [Fwd: Re: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)]
Re: images in html email. It's not just images. There are other tags - embed, etc. And if Microsoft Word becomes very intertwined with IE (word uses IE to fetch stuff) then word documents with image/object links will also be an issue. Mix well and add a few macros to taste ;). Cheerio, Link.
Re: The Dangers of Allowing Users to Post Images
Unfortunately, using client IP in access controls/sessions will render your service unusable for some people behind load balanced proxies. In such environment the source IP is not tied to the user, and will change every now and then between a set of different IP's (not to mention that there may be thousands of other users using the same IP). Also, please note that the class of attacks described here uses the users own browser, so your IP check won't do any good here as the attacks comes from the users own browser with his IP. Further, if you pass around the ticket in URLs then this class of attacks will also have full access to the ticket from the referer URL, so if you only base your security on these two measurements (client IP + ticket present in the URL) then your are most likely at risk here. Using a one-time ticket embedded in forms (not URL's) as key to enable actions, submitted only via POST (not GET), combined with proper protection from the cross-site-scripting family of vulnerabilities should render the service quite secure against these classes of vulnerabilities, assuming there is no cross-site vulnerabilities in the browsers used. In most applications only actions needs to be protected with tickets, not information retrieval. In such cases, the ticket should be created when the user initiates an action, and only be valid for that specific action. Lets take a discussion forum as an example. There the ticket should be created when the user selects to create a message or reply. This ticket then enables the user to submit this message to the forum. While the user is only browsing the discussion forum there should not exists any ticket. To be friendly to your users a limited set of tickets should be allowed to be active (i.e. more than one but less than many). How many depends on how many actions (composing messages or whatever) you allow the user to perform in parallel. Regarding the discussion on Referer checks. These are quite weak and won't necessarily gain you anything in terms of security. It is well known that Referer can be forged, and to further add to this some browsers preserve Referer when following redirects, allowing this kind of attacks to bypass any Referer check if your users follows URL's (direct or indirect via images) posted by other users or even your own staff when linking to external sites. My recommendations in short: 1. Use one-time tickets to verify then intent whenever a user performs an action that modifies data. 2. Make sure the application is fully protected from cross-site-scripting (and in this case cross-user-scripting) issues. 3. If your intention is that the users are not allowed to link directly into your application then use Referer checks, but do not rely on this for verifying intent. There are other measurements much more reliable. 4. Do not rely on the client IP in session management. There are plenty of legitimate cases where the client IP is not static and may change in between two requests of the same session. 5. Use SSL to encrypt the traffic. However, compared to the basic risks discussed here encryption is only a minor thing, and won't by itself solve anything. -- Henrik Nordstrom Squid HTTP proxy developer Tim Nowaczyk wrote: My company implemented this but went one more step. They created a file that had (IP, ticket) pairs. The ticket was passed around in URLs, but wasn't valid unless it came from the specific IP. To pretend to be someone else, one would have to spoof their IP and guess the value of their (10 hour life-cycle) ticket. We did this, originally, because we wanted to support web browsers that didn't use cookies. The file was, actually, more like (IP, ticket, cookie-type-options-and-settings). It worked well for us. Sincerely, Tim Nowaczyk Truth
Re: The Dangers of Allowing Users to Post Images
On 15 Jun 01 at 12:52, [EMAIL PROTECTED] wrote: When the request comes in, check if the incoming ticket matches the one stored in this user's session. If it does, this particular user was given the offer by our server, and not by anyone else. To spoof this system, someone would have to guess or otherwise find out what ticket value the victim was given by the server. To make it harder to find the ticket value given to a user, you could give the user many tickets, one for each possible action. This solution would require a ticket pool in the user's session. I've implemented the latter solution in both PHP and Java. Let me know if you would like some code. (It's not at all hard to implement, of course.) Sverre. My company implemented this but went one more step. They created a file that had (IP, ticket) pairs. The ticket was passed around in URLs, but (1) wasn't valid unless it came from the specific IP. To pretend to be someone else, one would have to spoof their IP and guess the value of ^^(2) ^^^(3) their (10 hour life-cycle) ticket. We did this, originally, because we wanted to support web browsers that didn't use cookies. The file was, actually, more like (IP, ticket, cookie-type-options-and-settings). It worked well for us. (2) should be extended with or to use the same proxy. (3) becomes much more simple due to (1), especially because if you allow inline images, the browser will supply the ticket in Referer: header when requesting the image. So, in many cases this extra step gives more cons than pros. But if sending such tickets via POST instead of URLs, this step is a good thing. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13
Re: The Dangers of Allowing Users to Post Images
According to Tim Nowaczyk: My company implemented this but went one more step. They created a file that had (IP, ticket) pairs. The ticket was passed around in URLs, but wasn't valid unless it came from the specific IP. To pretend to be someone else, one would have to spoof their IP and guess the value of their (10 hour life-cycle) ticket. We did this, originally, because we wanted to support web browsers that didn't use cookies. The file was, actually, more like (IP, ticket, cookie-type-options-and-settings). It worked well for us. You are lucky. There are two cases which will invalidate this solution: 1) A bunch of users are behind a single web proxy (such as squid) so they all appear to come from the same IP address. This means you will have multiple tickets for the same IP. 2) A bunch of users are behind a multi-parented web proxy, in which case the users will appear to come from one of a number of addresses. This leads to bizarre behaviour - the user authenticates successfully but gets kicked off later because the ticket/IP pair don't match because a different parent to the one the user authenticated on happened to handle the request. -- === Brett Lymn, Computer Systems Administrator, BAE SYSTEMS ===
Re: The Dangers of Allowing Users to Post Images
(replying to two messages at once here) On Thu, 14 Jun 2001, Ben Gollmer wrote: This is not a big deal if you use some validation on images (in PHP at least). Try the function getImageSize(); it will return an array containing the size of the image, as well as the format. If the file specified is not a GIF, JPEG, PNG, or SWF, getImageSize() returns null. Simply verifying it once before you accept the post is not sufficient. It is easy to point to something that is a valid image at the time of the post, but then later change that to be a redirect to a compromising URL. And verifying it every time or uploading the image to be stored on the server can be quite slow or resource intensive, respectively. On Thu, 14 Jun 2001, Richard M. Smith wrote: This is a *very* interesting finding. It seems kind of obvious too. I wonder why no one seems to have run across it before. People have. It just isn't something the world in general cares much about, like most other security vulnerabilities that aren't presented in the way of a particular, high profile, example. A lot of these issues are fairly closely related to cross site scripting related issues that are still rampant on many sites. This same weakness can be exploited from an HTML email message also. The bottom line is that a privileged operation should always require an HTTP POST and never allow a GET. Hmm, I wonder how many Web sites break this rule? At least in Outlook 2002, cookies are disabled in HTML email messages by default. With other email readers, cookies are likely turned on by default. Interesting how cookies continue to bite us in the butt! In this situation, it is third-party cookies that are doing the biting. It isn't cookies that are the problem in particular. The same issues come up regardless of what automatic long-lived login (or even session logins in the case of a message board where the viewing of HTML that results in the browser performing an action with unexpected results) authentication scheme is being used. This can be an issue with cookies. This can be an issue with HTTP basic auth, digest auth, NTLM auth, and even SSL client certificates. All provided they are setup to automatically send the authentication to the server without prompting the user, or that the user accepts any dialog box because that is what they normally do. Actually, using SSL client certificates for strong authentication, given weak UI implementations in today's clients, really scares me. Not because the authentication isn't cryptographically strong, but simply because it is too transparent to the user.
Re: The Dangers of Allowing Users to Post Images
The interesting part of this bug is the fact that its exploitable on some very large sites, and is open to a large number of users. Bulletin boards in particular allow inline image posting, and this is what creates the problem...inline images in a system with cookie based authentication. One system that has been entirely ignored in the conversation thus far is webmail services. Many webmail clients inline HTML parts leaving themselves susceptible to attack. More importantly, systems that provide single sign on to several services through cookie based systems (i.e. a portal) make themselves even more vulnerable. Imagine a portal with webmail. A user receives an inlined image which has it's source URL pointing to some service on that portal's network. That request is now authorized as far as the portal's concerned. Even if the mail application is secure from attack, there's no guarantee that all other services on the portal network are secure. This technique has more issues than just false authentication, though, and could possibly be used towards distributed DoS type attacks. Some forums have 50k+ users, and each user who viewed a certain thread could be accessing some resource intensive script on a remote server. If posted on several highly trafficed forums, the victimized server would go down in no time. The DoS attack is actually much worse than it sounds. Imagine posting an HTML message with an image tag to a newsgroup, instead of a web forum, with heavy traffic (some porn images group). If the image tag had it's source pointing to a common URL, it could quickly bring that site down due to the volume of people downloading the message from the newsgroup and referencing the image tag contained within. Ryan Kennedy
Re[2]: The Dangers of Allowing Users to Post Images
Following upon the letter of Friday, June 15, 2001: RMS This is a *very* interesting finding. It seems kind of obvious RMS too. I wonder why no one seems to have run across it before. It reminds me Client Side Trojans thread. Also similar problem with authorization have been described at tools-on.net (Web and your privacy section). The problem is that once authorised you don't have to enter password again if you are redirected to some form inside protected (via .htaccess, cookie, etc) area. Best regards, Alexander --- MCP+I, MCSE, BrainBench certificates http://leader.ru http://tools-on.net ---
Re: The Dangers of Allowing Users to Post Images
On Thu, Jun 14, 2001 at 09:12:05PM -0400, Chris Lambert wrote: would it be safe to check that if a referer is present, it contains the sites' domain name, Yes. but if it isn't, it most likely wouldn't have been referenced in an img tag or submitted via JavaScript? You mean it's safe/legitimate? No. Client-pull META tags generate requests without Referers, as I've said a couple times in this thread, and in previous Bugtraq discussions, too. :-) If you don't see the Referer, you can't trust the request. Your best bet is to lock out users who won't pass Referers. Or at least, when you initialize a user session, note if they seem to be passing Referer values. If they are, then you should certainly reject any later request that seems to be theirs, but lacks a Referer header. Note that in some cases, MSIE won't send a Referer if the TARGET of a link is a different window, or that used to be the case. This is messy. -Peter
Re: The Dangers of Allowing Users to Post Images
On Thu, Jun 14, 2001 at 08:34:33PM +0200, Sverre H. Huseby wrote: A possible solution (for web developers) seems to be to make sure the user has been given an offer to do something before letting him do it: Give each user a unique ticket, and for each action on a web page, bind this ticket to it. Examples on URL an form follow: http://vote.com/vote.cgi?answer=1ticket=9871398747 input type=hidden name=ticket value=9871398747 When the request comes in, check if the incoming ticket matches the one stored in this user's session. If it does, this particular user was given the offer by our server, and not by anyone else. To spoof this system, someone would have to guess or otherwise find out what ticket value the victim was given by the server. To make it harder to find the ticket value given to a user, you could give the user many tickets, one for each possible action. This solution would require a ticket pool in the user's session. I've implemented the latter solution in both PHP and Java. Let me know if you would like some code. (It's not at all hard to implement, of course.) Sverre. My company implemented this but went one more step. They created a file that had (IP, ticket) pairs. The ticket was passed around in URLs, but wasn't valid unless it came from the specific IP. To pretend to be someone else, one would have to spoof their IP and guess the value of their (10 hour life-cycle) ticket. We did this, originally, because we wanted to support web browsers that didn't use cookies. The file was, actually, more like (IP, ticket, cookie-type-options-and-settings). It worked well for us. Sincerely, Tim Nowaczyk Truth
Re: The Dangers of Allowing Users to Post Images (fwd)
At 10:29 AM 6/15/01 -0400, Shafik Yaghmour wrote: Yeah this is kind'a old if you have been developing sites for a while, you also need to consider that someone can also do this off the site as well. So if they have the ability to link to a site from your site they can get people to go to that site and then do the post from that site and this defeats this protection. Therefore, although, everyone disparages HTTP_REFERER checking, in this case it will protect the innocent user. I agree, it's an old problem (well as long as the web has been around :) ) and there are various ways to try to solve it depending on the circumstances. I did post to vuln-dev regarding this last year - asking for other people's ideas on how they solve it (Subject: How to prevent malicious linking/posting to webapps?). For critical areas you could also force the user to enter their password or something similar which will also prevent this attack from working. This does work reasonably well, but I'd reserve this for very critical areas only (Are you sure you want to buy 10 million shares of Company X). This is used in at least one local bank. If you use this too often the users get annoyed, but so far they like it when it's used judiciously. For less critical but still important things, I've been using confirmation pages and checksums. Basically, the cgi parameters are passed to the app. If there's no confirmation value, a confirmation value is generated using a cryptographic hash of the active session's random string, the relevant cgi parameters, and a secret, then a confirmation form is displayed with hidden fields containing those parameters. If the user clicks yes, the values are resubmitted along with the new valid confirmation value. If the user clicks no, the user is returned to the calling page using the decoded stack cgi parameter (if present) . If an invalid confirmation value is provided, the app logs the attempt and the HTTP-Referer, and displays the confirmation form with a warning as well. Only if the confirmation value is correct will the action take place. One problem of linking confirmation values to the session is that if the user times out the forms have to be reloaded, regenerated and some info might be lost. For example, if user is typing out a message in a form containing the confirmation value but times out, if the user clicks submit, the user has to log in again. If it weren't for the confirmation value being tied to the session, the user's data could be submitted automatically after a successful login. I still prefer it being tied to the session tho, because that reduces further the chance of replay attacks - once the session is invalid, you can't use that confirmation value anymore, even if it's for the same action and same objects. Regards, Link.
Re: The Dangers of Allowing Users to Post Images
[www-mobile-code would probably be a more appropriate list for this] It seems to me that what you talk about is Client Side Trojans, which were discussed in the Zope forum in May last year. http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan This is a far reaching security problem. The links you talk about may just as well be sent in mail, or they may be viewed from a different web site. Mails and different web sites may include JavaScript that posts prefilled forms on behalf of the user, so using POST rather than GET will not fully solve the problem. As long as the user is already authenticated to the site in questions. Some sites offering always logged in, and intranets using eg. NTLM authentication are particularly vulnerable to this kind of attack. A possible solution (for web developers) seems to be to make sure the user has been given an offer to do something before letting him do it: Give each user a unique ticket, and for each action on a web page, bind this ticket to it. Examples on URL an form follow: http://vote.com/vote.cgi?answer=1ticket=9871398747 input type=hidden name=ticket value=9871398747 When the request comes in, check if the incoming ticket matches the one stored in this user's session. If it does, this particular user was given the offer by our server, and not by anyone else. To spoof this system, someone would have to guess or otherwise find out what ticket value the victim was given by the server. To make it harder to find the ticket value given to a user, you could give the user many tickets, one for each possible action. This solution would require a ticket pool in the user's session. I've implemented the latter solution in both PHP and Java. Let me know if you would like some code. (It's not at all hard to implement, of course.) Sverre. -- URL:mailto:[EMAIL PROTECTED] URL:http://shh.thathost.com/
RE: The Dangers of Allowing Users to Post Images
This is a *very* interesting finding. It seems kind of obvious too. I wonder why no one seems to have run across it before. This same weakness can be exploited from an HTML email message also. The bottom line is that a privileged operation should always require an HTTP POST and never allow a GET. Hmm, I wonder how many Web sites break this rule? At least in Outlook 2002, cookies are disabled in HTML email messages by default. With other email readers, cookies are likely turned on by default. Interesting how cookies continue to bite us in the butt! In this situation, it is third-party cookies that are doing the biting. Of course, with JavaScript enabled in email, a malicious message can still do a POST. Yet another reason to turn off JavaScript in email. Richard M. Smith CTO, Privacy Foundation http://www.privacyfoundation.org -Original Message- From: John Percival [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 2:33 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: The Dangers of Allowing Users to Post Images This exploit shows how almost any script that uses cookie session/login data to validate CGI forms can be exploited if the users can post images. One of our developers, Chris 'stallion' Lambert ( [EMAIL PROTECTED] ), discovered this exploit in a routine internal security audit. Allowing users to post inline images is potentially a bad thing. Having the user authentication based solely on cookies is another potentially bad thing. When you put them together, it gets a whole lot worse. I will explain this problem with reference to a typical forum system, but naturally, it can be extended to almost any other CGI script, not just limited to PHP scripts. We have also tested this with Infopop's Ultimate Bulletin Board 6.04e, ezboard 6.2 and WWW Threads PHP 5.4, and at the time of writing, all three were susceptible to attack.
Re: The Dangers of Allowing Users to Post Images
This is not a big deal if you use some validation on images (in PHP at
least).
Try the function getImageSize(); it will return an array containing the
size of the image, as well as the format. If the file specified is not a
GIF, JPEG, PNG, or SWF, getImageSize() returns null.
This is also beneficial if you don't want users posting huge images to
your forum. In this code, the image must be 800x600 or less.
?php
//quick sample code follows
//$imagePath is the URL provided; doesn't matter if its via GET or POST
$imageInfo = getImageSize($imagePath);
if(!$imageInfo)
{
print(Sorry, image cannot be opened or is not a valid image type.);
}
elseif($imageInfo[0] = 800 || $imageInfo[1] = 600)
{
print(Sorry, image too big);
}
//and so on
?
More info here: http://www.php.net/manual/en/function.getimagesize.php
Ben Gollmer
Jatosoft, LLC
Re: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)
- Original Message - From: Peter W [EMAIL PROTECTED] Subject: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images) | I hope you don't mind if I expand on this a bit. You've come across the | tip, in my opinion, of a rather large iceberg. It's another | Web/trust-relationship problem. Many Web applications are fairly good at | identifying users and understanding requests, but terrible at verifying | origins and intent. Yes, and oddly enough, its an iceberg thats been floating all around us for ages. | The problem isn't the IMG tag on the message board, it's the backend app | you seek to attack via the IMG tag. And I suspect lots of Web apps are | vulnerable. Lots. I've been to training on highly-regarded, widely-used, | expensive Web app development frameworks, and none of the classes taught | how to avoid the problems I will attempt to describe. In fact, they all | seem to teach the easy way of handling what look like user requests, | which is, of course, the vulnerable way. Yes, you're correct that its the target of the exploit which needs to be protected. However, the reason we originally related it to message boards was because the source and the target were tightly related. I could use an image on a message board to, as you suggested, make an online transaction at an online store. However, only users who had registered and logged in at that store would be effected. With message boards, or any other script with cookie based authentication AND inline image support, the exploit will suceed every time. In PHP especially, the ability to access variables via $theirname regardless of whether they are POST, GET, COOKIE, or SERVER creates a problem. Its easily fixed, though, by simply referencing the respective predefined array for the element ($HTTP_POST_VARS[], $HTTP_GET_VARS[], etc...) but the problem will remain simply because its what makes PHP easy for the beginner. | Right. There's something much larger going on here. Darnit, I wanted to | make a nice formal paper out of this, but you're forcing my hand. :-) The | problem is what I call CSRF (Cross-Site Request Forgeries. You going to the O'Reilly Conference in San Diego? We should meet up to discuss this further...maybe setup a BOF to brainstorm the far reaching effects of CSRF and all the possible solutions for it. | img src=https://trading.example.com/xfer?from=MSFTto=RHATconfirm=Y; | img src=https://books.example.com/clickbuy?book=ISBNherequantity=100; Eek! While its a problem, the user exposed WOULD have to be registered on the target site, and unless the target site is the source site, its not as much of an issue as inter-system attack would be. Inter-system being, for example, an image referenced on an EBay product page which bids on the item featured on the page. | Since HTML documents are popping up everywhere (even in corporate email | systems!!!), and it's impossible to discern what IMG or HREF values might be | direct CSRF attacks, or redirect users to unwittingly do dangerous things | via CSRF redirects, the fix has to be in the applications that do the | interesting things. Exactly. | That's it. When your client requests /logo.gif -- exposing no cookies -- the | example.net server redirects you to a URL like the one you show, above. So | the end result us the same as if the attacker had embedded the more obvious | URL inside the IMG tag. Opera lets you disable automatic 302 redirection. Probably a good idea if the redirect takes you off site. | If an attacker wants, he can also use a simple, innocent looking hyperlink | and hope the victim clicks on it (http://example.net/kyotoanalysis.htm). You | don't allow hyperlinks? Well, someone might copy/paste the link, and be | stung that way. They'd notice? Maybe not -- the URL could be a mostly useful | page, with a tiny frameset sliver that loads your attack URL. This has always been a problem, and as you mentioned above, the target site has to implement the fix. However, with the many scripting tricks available today, we're not being left with many options. | The fix MUST be implemented on the backend that's being attacked. In your | example, newreply.cgi needs to be intelligent enough to detect and stop CSRF | attacks. | We've talked about how an attacker can post a message to the messageboard | with innocent looking URLs. But an attacker can also simply send the | victim a piece of HTML email including the full attack IMG URL. No amount | of IMG tag filtering in your messageboard posting system can stop that. We haven't implemented any img tag filtering, IIRC. John just wanted to throw out a bunch of ideas as to what was possible. | ** The 90% solution: Referer tests This would work, but not all clients pass referers. For referer checking, I'd suggest validating the form if the referer matches correctly, or if no referer exists. Although not the perfect solution, I think that it'd be a safe bet. Let's say 1% of all clients don't pass
Re: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)
On Fri, Jun 15, 2001 at 02:09:57AM -0400, Chris Lambert wrote: Yes, you're correct that its the target of the exploit which needs to be protected. However, the reason we originally related it to message boards was because the source and the target were tightly related. Yes, of course. It's a ripe target. Low-lying fruit. Worth special concern. | img src=https://trading.example.com/xfer?from=MSFTto=RHATconfirm=Y; | img src=https://books.example.com/clickbuy?book=ISBNherequantity=100; Eek! While its a problem, the user exposed WOULD have to be registered on the target site, and unless the target site is the source site, its not as much of an issue as inter-system attack would be. Inter-system being, for example, an image referenced on an EBay product page which bids on the item featured on the page. Yes, the tightly coupled attack is definitely more effective. I can imagine a fair number of shenanigans on Slashdot et. al. if they're vulnerable, e.g., Anonymous Cowards posting links to what purports to be useful information... but I'm more concerned about things like commerce sites and webmail sites. As one pf the long messages reference in my long bugtraq post points out, I expect on many webmail systems an attacker could use CSRF to make a victim send abusive email without their knowledge. With more governments like that of the United Kindom bringing transactional capabilities to the Web, I hope developers will pay serious attaention to the problems of verifying origin and intent. Opera lets you disable automatic 302 redirection. Probably a good idea if the redirect takes you off site. Yes, that does sound like generally a good idea, but it would frustrate some applications that expect the usual behavior (I've written some such apps myself). I wonder how it would work in HTML mail clients, though? You could restrict to the sender's domain, but email is the easiest thing in the world to spoof. (And an effective attack vector, especially against things like messageboards that expose email addresses.) HTML email is just evil evil evil. I can't see much need for HTML email to reference *any* external documents, or to allow, as Jay Beale suggested, the use of things like META refresh tags to effect client-pull CSRF attacks. | ** The 90% solution: Referer tests This would work, but not all clients pass referers. For referer checking, I'd suggest validating the form if the referer matches correctly, or if no referer exists. Although not the perfect solution, I think that it'd be a safe bet. Let's say 1% of all clients don't pass referers. The 1% would be validated, therefore preventing them from getting an error when simply interacting as usual. I haven't thought this through very much. But check the securityfocus URL in my post; in my testing, 100% of clients will not send Referer information in client-pull (META refresh) scenarios. So be careful when working with your 1% rule: with client-pull, an attacker can make anyone suppress Referer information. | snipped Passing tokens or tokenized field names /snipped Good idea, looks to be the best solution yet. The problem with tokenized argument names is the /logo.gif 302 attack. If an attacker embeds an IMG reference to /logo.gif on their server, then their server is passed a Referer (in most cases, probably 99%+) that exposes the argument names used to read the CSRF message. I suspect you would not be (socially) able to rename the arguments with each page delivered. Doing things like that really frustrates users. I've tried it, and had to back out such protection on applications used by regular folks. The one-time-use authorization tokens seem to be solid, though. And easy to use, once you've got the basic Create/Verify/Invalidate methods written. | I'm afraid CSRF is going to be a mess to deal with in many cases. | Like trying to tame the seas. I'm in the process of launching a company that will secure web enabled applications from these, and other, types of attacks. CSRF seems to be one of the more generic types of holes which can be exploited, but there are certainly plenty more when dealing with user input, file handling, and database access. A pattern I've seen in Web deveopment over the years -- and I suspect it's not just the relatively young Web area that exhibits this -- is that developers tend to be more paranoid when building applications for pulic / unathenticated access. They tend to let their guards down when writing applications for users who are logged in. The thinking often goes something like this: Well, if the site's editor is logged in and asks to do something stupid, that's *her fault* and I'm not going to make this management application idiot-proof. Hopefully this discussion of CSRF helps explain the importance of making sure the HTTP request your application handles really is the site's editor asking to do somethign stupid, and not simply reading an HTML email with a CSRF IMG
Re: The Dangers of Allowing Users to Post Images (fwd)
Yeah this is kind'a old if you have been developing sites for a while, you also need to consider that someone can also do this off the site as well. So if they have the ability to link to a site from your site they can get people to go to that site and then do the post from that site and this defeats this protection. Therefore, although, everyone disparages HTTP_REFERER checking, in this case it will protect the innocent user. For critical areas you could also force the user to enter their password or something similar which will also prevent this attack from working. You also need to filter out javascript if you allow the user to craft their own image tags, this is a much worse problem becasue they can then claim the users cookie, encryption won't help you here. Of course they could also do other bad things with javascript. ( It has been pointed out to me that most tools out there already filter, I am just trying to be complete, there may be some following the discussion that this is not clear to ) As well if you do encypt cookies and you use lets say Mcrypt_CFB be careful, if data items fall within a block they can twiddle bits and corrupt data, in that block while leaving other blocks intact so I would advise attaching a HASH of all the data in the cookie at the end, so if you use a good HASH like MD5 it should be impossible for them to corrupt cookie without you knowing, if you check. I had at one point thought it would be useful to use IPs to verify users identity but AOL proxies do not maintain IP Addresses so a users IP can change rapidly as well they vary over the whole 2 last octets of the IP so you can't even validate that they come from the same C class network. AOL is far from the only one that does this, I have even seen a users IP vary over different A class networks, IIRC they where from Sympatico. Take care Wed, 13 Jun 2001, John Percival wrote: How can it be fixed? Well, there are a couple of ways to stop it, but the easiest (in PHP at least) seems to be to have most of the variables used by scripts be used through $HTTP_POST_VARS. So instead of checking for $action in a script, $HTTP_POST_VARS['action'] would be checked. This forces the user to use a POST request, not a GET. Alternatively, the sessionid could be required to come with the GET/POST request variables, rather than by cookie. Finally, in the specific case of [img] tags, the use of ? or in the img URL can be disabled by some regexes. == --the more you know and understand the more you must know and understand .. knowledge is an unsatiable hunger .. which makes life easier and at the same time harder knowledge is a paradox w/ no resolution just a boundless function of human nature knowledge is a trap which we embrace and which we run away from and in the end the only escape is death or maybe not grin-- == -This message transmitted on 100% recycled electrons- -Save the whales, Feed the hungry, Free the mallocs- Two cats on a roof, Which one falls off first? The one with the smaller mew.
Re: The Dangers of Allowing Users to Post Images
This exploit shows how almost any script that uses cookie session/login data to validate CGI forms can be exploited if the users can post images. One of our developers, Chris 'stallion' Lambert ( [EMAIL PROTECTED] ), discovered this exploit in a routine internal security audit. Allowing users to post inline images is potentially a bad thing. Having the user authentication based solely on cookies is another potentially bad thing. When you put them together, it gets a whole lot worse. I will explain this problem with reference to a typical forum system, but naturally, it can be extended to almost any other CGI script, not just limited to PHP scripts. We have also tested this with Infopop's Ultimate Bulletin Board 6.04e, ezboard 6.2 and WWW Threads PHP 5.4, and at the time of writing, all three were susceptible to attack. What is the problem? Well, by using an [img] (or HTML img or iframe or script src=) tag, the user is having anyone who views the thread access that image - that is perform an HTTP GET on the URL specified for the image. Even if its not an image, it still can be accessed, but will display a broken image. This means that the user can put a CGI script inside [img] tags. This script will be called by whoever views that thread. When used maliciously, it could force the user to: unknowingly update their profile, respond to polls in a certain way, post new messages or threads, email a user with whatever text they want, the list goes on. This would be particularly worrying for a 'worm' to spread through a forum, filling it with rubbish posts. For example, if a user posted something along these lines: [img]http://your.forums/forums/newreply.cgi?action =newthreadsubject=aaabod y=some+naughty+wordssubmit=go[/img] Then the post would go through, under the name of whoever viewed the image. This is of particular danger when an administrator views an image, which then calls a page in an online control panel - thus granting the user access to the control panel. How can it be fixed? Well, there are a couple of ways to stop it, but the easiest (in PHP at least) seems to be to have most of the variables used by scripts be used through $HTTP_POST_VARS. So instead of checking for $action in a script, $HTTP_POST_VARS['action'] would be checked. This forces the user to use a POST request, not a GET. Alternatively, the sessionid could be required to come with the GET/POST request variables, rather than by cookie. Finally, in the specific case of [img] tags, the use of ? or in the img URL can be disabled by some regexes. If the software that you run is not secure, we recommend that you disable HTML and/or [img] tags, until the fixes have been implemented. Known Vulnerable: Infopop's UBB 6.04e (probably the whole 6.xx series), ezboard 6.2, WWW Threads PHP 5.4, vBulletin 2.0.0 Release Candidate 2 and before (later versions are safe). Probably many more bulletin boards and CGI scripts out there, but those are the main ones that we have been tested positive. John Percival Product Manager, vBulletin http://www.vbulletin.com/ mailto:[EMAIL PROTECTED] vBulletin: Community Instantly Copyright 2001 Jelsoft Enterprises Ltd Infopop Corporation's current version of the Ultimate Bulletin Board™ Version, 6.04f (released 06-12-2001 05:58 PM), does not have this vulnerability. Our OpenTopic™ product has never had this vulnerability.
Re: The Dangers of Allowing Users to Post Images
Unfortunately, there are way too many sites which simply use HTTP GET. Why? Well, in PHP, variables submitted to the form are all accessible via $theirname upon start of execution. This is a feature for the lazy, as they don't have to reference array $HTTP_POST_VARS, array $HTTP_GET_VARS, or array $HTTP_COOKIE_VARS. So, most PHP scripts taking user input (chat scripts, message boards, poll scripts, user comments, anything...) will consider a POST var the same as a GET var. In Perl, because it wasn't originally tailored to the web (although I don't have much experience with it), I believe that GET is seperated from POST. Yes, it is surprise that this hasn't posted before. The Zope page Sverre linked to is similar, but didn't make the connection with inline images. -- WhiteCrown Networks - Web Application Security www.whitecrown.net - [EMAIL PROTECTED] __ / Chris Lambert - [EMAIL PROTECTED] |- ICQ #: 16435685 - AIM: ClipperChris `- Cell: (401) 743-2786 - http://sms.clambert.org/ - Original Message - From: Richard M. Smith [EMAIL PROTECTED] | This is a *very* interesting finding. It seems | kind of obvious too. I wonder why no one seems | to have run across it before. | This same weakness can be exploited from an | HTML email message also. The bottom line is that | a privileged operation should always require | an HTTP POST and never allow a GET. Hmm, I wonder how many | Web sites break this rule? | Richard M. Smith | CTO, Privacy Foundation | http://www.privacyfoundation.org
Re: The Dangers of Allowing Users to Post Images
Most message boards filter out JavaScript by default. About referer checking, there are many clients which either do not send, or give the user the option to not send, HTTP_REFERERs. Therefore, it wouldn't be a good move to rely solely on checking the referer. However, would it be safe to check that if a referer is present, it contains the sites' domain name, but if it isn't, it most likely wouldn't have been referenced in an img tag or submitted via JavaScript? -- WhiteCrown Networks - Web Application Security www.whitecrown.net - [EMAIL PROTECTED] __ / Chris Lambert - [EMAIL PROTECTED] |- ICQ #: 16435685 - AIM: ClipperChris `- Cell: (401) 743-2786 - http://sms.clambert.org/ - Original Message - From: Shafik Yaghmour [EMAIL PROTECTED] | Yeah this is kind'a old if you have been developing sites for a | while, you also need to consider that someone can also do this off the | site as well. So if they have the ability to link to a site from your | site they can get people to go to that site and then do the post from that | site and this defeats this protection. Therefore, although, everyone disparages | HTTP_REFERER checking, in this case it will protect the innocent user. | You also need to filter out javascript if you allow the user to | craft their own image tags, this is a much worse problem becasue they can | then claim the users cookie, encryption won't help you here. Of course | they could also do other bad things with javascript.
The Dangers of Allowing Users to Post Images
This exploit shows how almost any script that uses cookie session/login data to validate CGI forms can be exploited if the users can post images. One of our developers, Chris 'stallion' Lambert ( [EMAIL PROTECTED] ), discovered this exploit in a routine internal security audit. Allowing users to post inline images is potentially a bad thing. Having the user authentication based solely on cookies is another potentially bad thing. When you put them together, it gets a whole lot worse. I will explain this problem with reference to a typical forum system, but naturally, it can be extended to almost any other CGI script, not just limited to PHP scripts. We have also tested this with Infopop's Ultimate Bulletin Board 6.04e, ezboard 6.2 and WWW Threads PHP 5.4, and at the time of writing, all three were susceptible to attack. What is the problem? Well, by using an [img] (or HTML img or iframe or script src=) tag, the user is having anyone who views the thread access that image - that is perform an HTTP GET on the URL specified for the image. Even if its not an image, it still can be accessed, but will display a broken image. This means that the user can put a CGI script inside [img] tags. This script will be called by whoever views that thread. When used maliciously, it could force the user to: unknowingly update their profile, respond to polls in a certain way, post new messages or threads, email a user with whatever text they want, the list goes on. This would be particularly worrying for a 'worm' to spread through a forum, filling it with rubbish posts. For example, if a user posted something along these lines: [img]http://your.forums/forums/newreply.cgi?action=newthreadsubject=aaabod y=some+naughty+wordssubmit=go[/img] Then the post would go through, under the name of whoever viewed the image. This is of particular danger when an administrator views an image, which then calls a page in an online control panel - thus granting the user access to the control panel. How can it be fixed? Well, there are a couple of ways to stop it, but the easiest (in PHP at least) seems to be to have most of the variables used by scripts be used through $HTTP_POST_VARS. So instead of checking for $action in a script, $HTTP_POST_VARS['action'] would be checked. This forces the user to use a POST request, not a GET. Alternatively, the sessionid could be required to come with the GET/POST request variables, rather than by cookie. Finally, in the specific case of [img] tags, the use of ? or in the img URL can be disabled by some regexes. If the software that you run is not secure, we recommend that you disable HTML and/or [img] tags, until the fixes have been implemented. Known Vulnerable: Infopop's UBB 6.04e (probably the whole 6.xx series), ezboard 6.2, WWW Threads PHP 5.4, vBulletin 2.0.0 Release Candidate 2 and before (later versions are safe). Probably many more bulletin boards and CGI scripts out there, but those are the main ones that we have been tested positive. John Percival Product Manager, vBulletin http://www.vbulletin.com/ mailto:[EMAIL PROTECTED] vBulletin: Community Instantly Copyright 2001 Jelsoft Enterprises Ltd
