Finally find below the cheat sheet (dozens of manual test cases) for detection / prevention of this XSS attack to the webapplications: http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet http://ha.ckers.org/xss.html
Regards Sandeep Thakur On Fri, May 21, 2010 at 9:44 AM, Srinivas Naik <[email protected]> wrote: > It took some time for me to go thru second paragrapg, but its the perfect > conclusion which was derived. > Ultimately this type of attack has a countermeasure only thru the Server > Application. > > Regards, > 0xN41K > > On Fri, May 21, 2010 at 10:03 PM, Sandeep Thakur <[email protected]>wrote: > >> Yes, It clarifies me Naik. The example is interesting though. >> >> So, as I said, its understood that only* web server generated error pages >> (error template stored on server) might be effected with XSS as it is >> displaying back the input passed from the client in this case. But, not any >> web application which is hosted on the webserver will do this as they have >> their own custom error pages where the inputs will be sanitized. >> >> The lesson from this for everyone is that we should carefully evaluate and >> report the successfull attacks like the below. If you are doing application >> security testing, you may point out this to the configuration management >> team of webserver as a recommendation. Whereas, reporting this error as XSS >> in application will not be appropriate as this is something to do with >> server. >> >> Your thoughts? >> >> >> Regards >> Sandeep Thakur >> >> >> On Fri, May 21, 2010 at 7:07 AM, Srinivas Naik <[email protected]>wrote: >> >>> I had a study on XSS even with HTTP protocol headers. I possible I can >>> give a real Demo of it; taking Flash file containg such malicious request to >>> the Server. >>> >>> Hope the below will give clear picture;;; >>> >>> 1. Upload the Flash content which has got the *Host* field injected with >>> XSS. >>> >>> *GET \ HTTP/1.1 >>> Host: <XSSScript> >>> Connection: close* >>> >>> *** Spoofed the HOST with XSS. >>> >>> 2. The Target server responses with some Error on the same Browser >>> something like below. (this is the source of it) >>> <html> >>> <head> >>> <title> 413 Request entity</title> >>> </head> <body> >>> The request fails >>> <address>Apache/2.xxx PHP/5.1.7 Server at *<XSSScript>* Port 80 >>> </address> >>> </body> >>> </html> >>> >>> I just tried putting in an understandable format. Hope I am clear. The >>> Response from Server is Just an Reflection of what HOST field contains in >>> the HTTP protocol header. >>> >>> Regards, >>> 0xN41K >>> >>> On Fri, May 21, 2010 at 7:02 PM, Sandeep Thakur >>> <[email protected]>wrote: >>> >>>> Can you show us a demonstration? I guess, webservers will never >>>> publish http headers related information (injected script in host string of >>>> http header) to the content of the website. If this is happening, then >>>> certainly attack might be possible. >>>> >>>> Simple example web can be used to see this case in realtime: >>>> http://web-sniffer.net/ >>>> >>>> The idea however behind is : You can call this as attack only when the >>>> given input(injected script) comes back executes in your browser or in some >>>> other system. >>>> >>>> Question here would not be how do we inject, rather where are we getting >>>> response? is it in the headers or content? is the attack successful? If >>>> yes, >>>> is it in browser or protocol headers? >>>> >>>> NOTE: only browsers knows about javascript not the protocol. >>>> >>>> >>>> Regards >>>> Sandeep Thakur >>>> >>>> >>>> On Fri, May 21, 2010 at 4:16 AM, N41K <[email protected]> wrote: >>>> >>>>> Even in this case we get the error page from the server itself. And >>>>> here the question would be how do u inject in HTTP header so, one of >>>>> the answer is using Flash objects. >>>>> >>>>> When you upload a flash object which has this header injection script >>>>> embedded in it; this makes the error occur and so, the attack is >>>>> successful. >>>>> >>>>> Regards, >>>>> 0xN41K >>>>> >>>>> On May 21, 3:18 pm, Sandeep Thakur <[email protected]> wrote: >>>>> > If you meant the below as error pages, then certainly XSS is possible >>>>> as you >>>>> > can see whatever was input you got same or partial information back. >>>>> But >>>>> > however, these are not error pages rather http headers based >>>>> manipulation. >>>>> > >>>>> > Usually error pages means, when you request for a some >>>>> page/login/some >>>>> > data/resource and if its not available then you will be given >>>>> standard >>>>> > sanitized error message as a page from server itselt... hope this >>>>> clarifies? >>>>> > >>>>> > Regards >>>>> > Sandeep Thakur >>>>> > >>>>> > On Fri, May 21, 2010 at 2:17 AM, N41K <[email protected]> wrote: >>>>> > > I just want to have some clarification here. The XSS for Error >>>>> Pages >>>>> > > is right one; please check the below technical details in-order to >>>>> > > prove that the Error Pages are also prone for XSS. >>>>> > >>>>> > > 1. Send HTTP RAW request to an Web Server where the Host Field >>>>> > > contains the XSS script. >>>>> > > 2. In return the response the client gets is the Fingerprint with >>>>> the >>>>> > > script inserted. >>>>> > >>>>> > > So, XSS is succesfully achieved thru Error Pages Even. >>>>> > >>>>> > > Ref: CVE-2007-6203 >>>>> > >>>>> > > Regards, >>>>> > > 0xN41K >>>>> > >>>>> > > On May 21, 1:54 am, Sandeep Thakur <[email protected]> wrote: >>>>> > > > Also the answer includes appended list from Kishore. Only except >>>>> error >>>>> > > > pages, all other things has to checked for XSS. Bcz error pages >>>>> would not >>>>> > > > take any input from client(Say:malformed input like javascript) >>>>> but >>>>> > > displays >>>>> > > > stored error codes to the client. If these stored error codes or >>>>> messages >>>>> > > > can be edited somehow, then yes, here also XSS exists.... >>>>> > >>>>> > > > So now, when we have seen several ways of testing XSS. Lets also >>>>> look at >>>>> > > > possible remediations and its outbreak again. >>>>> > >>>>> > > > Regards >>>>> > > > Sandeep Thakur >>>>> > >>>>> > > > On Thu, May 20, 2010 at 1:26 PM, Sandeep Thakur < >>>>> [email protected] >>>>> > > >wrote: >>>>> > >>>>> > > > > Ofcourse most applications on web are using "referrer". But, >>>>> when you >>>>> > > can >>>>> > > > > know cookie, why not the "referrer" using javascript? Try the >>>>> below in >>>>> > > any >>>>> > > > > opened windows' address bar: >>>>> > >>>>> > > > > javascript: alert(document.referrer); >>>>> > >>>>> > > > > Now that we are talking about impersonation with session >>>>> belonging to >>>>> > > > > particular user, let me share one real good example which >>>>> occurs mostly >>>>> > > on >>>>> > > > > Orkut. >>>>> > >>>>> > > > > In Orkut, sometimes when your system is infected with certain >>>>> kind of >>>>> > > > > malware you see lot many advertisements or some illicit scraps >>>>> are >>>>> > > being >>>>> > > > > written to all your contacts in orkut. How is it possible? >>>>> > >>>>> > > > > *Answer: Malware silently knows your active session in Orkut >>>>> and then >>>>> > > know >>>>> > > > > off about cookie / session parameters / other important >>>>> information >>>>> > > like >>>>> > > > > referrer and then start writing scraps. Again how does it write >>>>> scraps? >>>>> > > It >>>>> > > > > will just give the specially crafted javascript file input in >>>>> the >>>>> > > address >>>>> > > > > bar.* >>>>> > >>>>> > > > > Hope this clarifies? >>>>> > >>>>> > > > > And about the interview question of Naik, Probable answers are >>>>> All >>>>> > > optional >>>>> > > > > fields that returns back some or full information which you >>>>> have >>>>> > > entered at >>>>> > > > > the begining.. the answer should be: a,b,c,d >>>>> > >>>>> > > > > Regards >>>>> > > > > Sandeep Thakur >>>>> > >>>>> > > > > On Thu, May 20, 2010 at 8:25 AM, Phani < >>>>> [email protected]> >>>>> > > wrote: >>>>> > >>>>> > > > >> But now a days most of the applications is using referer >>>>> section to >>>>> > > check >>>>> > > > >> whether the application is accessed as specified or not. >>>>> > > > >> For Ex. if you access the change password page of a site by >>>>> > > > >> directly pasting the URL& hijacked Session ID from the >>>>> publicly >>>>> > > available >>>>> > > > >> Login page, then the server looks into referer section to >>>>> verify that >>>>> > > the >>>>> > > > >> request coming is genuine or not, because the change password >>>>> section >>>>> > > can >>>>> > > > >> accessed by the logged-in user only. >>>>> > >>>>> > > > >> Correct me if Im wrong >>>>> > >>>>> > > > >> On Thu, May 20, 2010 at 11:15 AM, kishore kumar < >>>>> [email protected] >>>>> > > >wrote: >>>>> > >>>>> > > > >>> appending to the list: >>>>> > >>>>> > > > >>> f) URL Parameters (http://abc.com?id=1<http://abc.com/?id=1> >>>>> <http://abc.com/?id=1> (xss >>>>> > > > >>> script) ) >>>>> > > > >>> g) all input feilds in application >>>>> > > > >>> h) all headers >>>>> > > > >>> i) hidden feilds >>>>> > >>>>> > > > >>> On 20 May 2010 10:47, N41K <[email protected]> wrote: >>>>> > >>>>> > > > >>>> I thought I can share some info of my technical >>>>> interview..... >>>>> > >>>>> > > > >>>> The Question was " Does XSS occur in All the inputs field >>>>> like input >>>>> > > > >>>> box / Address bar / etc..?" >>>>> > > > >>>> Answer (may be few are listed below) >>>>> > > > >>>> a) Search Field >>>>> > > > >>>> B) Comment Fields >>>>> > > > >>>> c) Feedback Forms >>>>> > > > >>>> d) Login Forms >>>>> > > > >>>> e) Error Pages >>>>> > >>>>> > > > >>>> Regards, >>>>> > > > >>>> 0xN41K >>>>> > >>>>> > > > >>>> On May 18, 9:42 pm, N41K <[email protected]> wrote: >>>>> > > > >>>> > Hi, >>>>> > >>>>> > > > >>>> > There are many ways to check if the Site or Web >>>>> Application is >>>>> > > > >>>> > Vulnerable to XSS. Few of them are stated below >>>>> > >>>>> > > > >>>> > <script>alert("XSS")</script> >>>>> > > > >>>> > /<script>alert('XSS')</script>/ >>>>> > > > >>>> > /\<script\>alert(\'XSS\')\<\/script\> >>>>> http://mysite.org/folder/\ <http://mysite.org/folder/%5C>< >>>>> http://mysite.org/folder/%5C> >>>>> > > <http://mysite.org/folder//> >>>>> > > > >>>> <sCRIPT>alert("d")</sCRIPT>\.plhttp://mysite.org/folder/\<http://mysite.org/folder/%5C> >>>>> <http://mysite.org/folder/%5C> >>>>> > > <http://mysite.org/folder//> >>>>> > > > >>>> >>>>> <sCRIPT>alert('d')</sCRIPT>\.pl/\<sCRIPT>alert("d")</sCRIPT>\ >>>>> > > > >>>> > \<sCRIPT>alert('d')</sCRIPT>\ >>>>> > > > >>>> > /<\73CRIP\T>alert("dsf")<\/\73CRIP\T> >>>>> > > > >>>> > /<\73CRIP\T>alert('dsf')<\/\73CRIP\T> >>>>> > > > >>>> > /</sCRIP/T>alert("dsf")<///sCRIP/T> >>>>> > > > >>>> > /</sCRIP/T>alert('dsf')<///sCRIP/T> >>>>> > >>>>> > > > >>>> > THe same above request can be sent using POST, which >>>>> represents >>>>> > > > >>>> > after ? after mysite.org: >>>>> > >>>>> > > > >>>> >http://mysite.org/?<script>alert("XSS")</script> >>>>> http://mysite.org/ >>>>> > > > >>>> ?<script>alert('XSS')</script>http://mysite.org/ >>>>> > > > >>>> ?\<script\>alert(\'XSS\')\<\/script\> >>>>> http://mysite.org/perl/ >>>>> > > > >>>> ?\<sCRIPT>alert("d")</sCRIPT>\.plhttp://mysite.org/perl/ >>>>> > > > >>>> ?\<sCRIPT>alert('d')</sCRIPT>\.plhttp://mysite.org/ >>>>> > > > >>>> ?\<sCRIPT>alert("d")</sCRIPT>\http://mysite.org >>>>> > > > >>>> \?<sCRIPT>alert('d')</sCRIPT>\http://mysite.org/ >>>>> > > > >>>> ?<\73CRIP\T>alert("dsf")<\/\73CRIP\T>http://mysite.org/ >>>>> > > > >>>> ?<\73CRIP\T>alert('dsf')<\/\73CRIP\T>http://mysite.org/ >>>>> > > > >>>> ?</sCRIP/T>alert("dsf")<///sCRIP/T>http://mysite.org/ >>>>> > > > >>>> ?</sCRIP/T>alert('dsf')<///sCRIP/T> >>>>> > >>>>> > > > >>>> > *** Also,The above tricks case be used to Test few >>>>> Security >>>>> > > Softwares >>>>> > > > >>>> > like WAF (Web Application Firewall) / IPS (Intrusion >>>>> Prevention >>>>> > > > >>>> > System) or IDS. >>>>> > >>>>> > > > >>>> > Regards, >>>>> > > > >>>> > 0xN41K >>>>> > >>>>> > > > >>>> > On May 18, 9:17 pm, N41K <[email protected]> wrote: >>>>> > >>>>> > > > >>>> > > So, Securing such application is very important. In >>>>> order to do >>>>> > > so, >>>>> > > > >>>> we >>>>> > > > >>>> > > need to take care of special functions which will not >>>>> allow the >>>>> > > > >>>> Remote >>>>> > > > >>>> > > Attackers to Execute the Scripts and take advantage of >>>>> it. >>>>> > >>>>> > > > >>>> > > Lets see actually how an vulnerable code for XSS look >>>>> like, then >>>>> > > > >>>> after >>>>> > > > >>>> > > that we'll secure the application by understanding the >>>>> right >>>>> > > line. >>>>> > >>>>> > > > >>>> > > So, Vulnerable PHP code would be something like this... >>>>> > >>>>> > > > >>>> > > <html> >>>>> > > > >>>> > > <head> >>>>> > > > >>>> > > <meta http-equiv="Content-Type" content="text/html; >>>>> > > > >>>> > > charset=iso-8859-1" /> >>>>> > > > >>>> > > <title>Search result:</title> >>>>> > > > >>>> > > <style type="text/css"> >>>>> > > > >>>> > > <!-- >>>>> > > > >>>> > > body,td,th { >>>>> > > > >>>> > > color: #FFFFFF;} >>>>> > >>>>> > > > >>>> > > body { >>>>> > > > >>>> > > background-color: #000000;} >>>>> > >>>>> > > > >>>> > > --> >>>>> > > > >>>> > > </style></head> >>>>> > > > >>>> > > <body> >>>>> > > > >>>> > > <span class="alert">Search result >>>>> :</span> <strong><?php >>>>> > > echo >>>>> > > > >>>> > > $_POST['Vulnerability']; ?></strong> >>>>> > > > >>>> > > </body> >>>>> > > > >>>> > > </html> >>>>> > >>>>> > > > >>>> > > Now the Secure Code for Vulnerable XSS will be: >>>>> > >>>>> > > > >>>> > > <html> >>>>> > > > >>>> > > <head> >>>>> > > > >>>> > > <meta http-equiv="Content-Type" content="text/html; >>>>> > > > >>>> > > charset=iso-8859-1" /> >>>>> > > > >>>> > > <title>Search result:</title> >>>>> > > > >>>> > > <style type="text/css"> >>>>> > > > >>>> > > <!-- >>>>> > > > >>>> > > body,td,th { >>>>> > > > >>>> > > color: #FFFFFF;} >>>>> > >>>>> > > > >>>> > > body { >>>>> > > > >>>> > > background-color: #000000;} >>>>> > >>>>> > > > >>>> > > --> >>>>> > > > >>>> > > </style></head> >>>>> > > > >>>> > > <body> >>>>> > > > >>>> > > <span class="alert">Search result >>>>> :</span> <strong><?php >>>>> > > > >>>> > > if(isset($_POST['Vulnerability'])) { echo >>>>> > > > >>>> > > htmlentities($_POST['Vulnerability']); } >>>>> ?></strong> >>>>> > > > >>>> > > </body> >>>>> > > > >>>> > > </html> >>>>> > >>>>> > > > >>>> > > The only difference is the replacement of function; we >>>>> tried to >>>>> > > make >>>>> > > > >>>> > > it secure by using htmlspecialchars(); >>>>> > >>>>> > > > >>>> > > Regards, >>>>> > > > >>>> > > 0xN41K >>>>> > >>>>> > > > >>>> > > On May 17, 9:10 am, kishore kumar <[email protected]> >>>>> wrote: >>>>> > >>>>> > > > >>>> > > > *Stealing Cookies With XSS* : >>>>> > >>>>> > > > >>>> > > > Using XSS to Steal Cookies >>>>> > >>>>> > > > >>>> > > > once u find out that a particular page is vulnerable >>>>> to XSS >>>>> > > > >>>> injection, Now >>>>> > > > >>>> > > > what? You want to make it do something useful, like >>>>> steal >>>>> > > cookies. >>>>> > > > >>>> Cookie >>>>> > > > >>>> > > > stealing is when you insert a script into the page so >>>>> that >>>>> > > > >>>> everyone that >>>>> > > > >>>> > > > views the modified page inadvertently sends you their >>>>> session >>>>> > > > >>>> cookie. By >>>>> > > > >>>> > > > modifying your session cookie, you can impersonate any >>>>> user >>>>> > > who >>>>> > > > >>>> viewed the >>>>> > > > >>>> > > > modified page. So how do you use XSS to steal cookies? >>>>> > >>>>> > > > >>>> > > > The easiest way is to use a three-step process >>>>> consisting of >>>>> > > the >>>>> > > > >>>> injected >>>>> > > > >>>> > > > script, the cookie recorder, and the log file. >>>>> > >>>>> > > > >>>> > > > First you'll need to get an account on a server and >>>>> create two >>>>> > > > >>>> files, >>>>> > > > >>>> > > > log.txt and cookiesteal.php. You can leave log.txt >>>>> empty. This >>>>> > > is >>>>> > > > >>>> the file >>>>> > > > >>>> > > > your cookie stealer will write to. Now paste this php >>>>> code >>>>> > > into >>>>> > > > >>>> your cookie >>>>> > >>>>> > ... >>>>> > >>>>> > read more ยป >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "nforceit" group. >>>>> To post to this group, send an email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]<nforceit%[email protected]> >>>>> . >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/nforceit?hl=en-GB. >>>>> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "nforceit" group. >>>> To post to this group, send an email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]<nforceit%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/nforceit?hl=en-GB. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "nforceit" group. >>> To post to this group, send an email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<nforceit%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/nforceit?hl=en-GB. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "nforceit" group. >> To post to this group, send an email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<nforceit%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/nforceit?hl=en-GB. >> > > -- > You received this message because you are subscribed to the Google Groups > "nforceit" group. > To post to this group, send an email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nforceit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nforceit?hl=en-GB. > -- You received this message because you are subscribed to the Google Groups "nforceit" group. To post to this group, send an email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nforceit?hl=en-GB.
