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