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> >>> (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]. For more options, visit this group at http://groups.google.com/group/nforceit?hl=en-GB.
