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