'xss'에 해당되는 글 5건

  1. 2012.09.25 HTML5 Top 3 Vulnerability by CEOinIRVINE 2
  2. 2012.09.25 HTML5 Security & Mobile by CEOinIRVINE
  3. 2011.03.04 Web Vulnerability regarding F company by CEOinIRVINE
  4. 2010.10.20 Amazon Seller XSS by CEOinIRVINE
  5. 2009.02.06 XSS Cheat Sheet by CEOinIRVINE

HTML5 Top 3 Vulnerability

Hacking 2012. 9. 25. 04:59

Top 3 HTML5 Vulnerability Risk Categories

Forrester urges HTML5 adoption, but security researchers say secure coding should be in place from the start

Aug 08, 2012 | 04:44 AM | 

By Ericka Chickowski, Contributing Writer
Dark Reading
 
New advice out from Forrester Research during the past week urges companies to step up the pace of their HTML5 adoption to keep up with mobility trends and enable better online customer experiences. But as HTML5 gains relevance in the enterprise, developers need to think carefully about the vulnerabilities that their new code may introduce into their organizations' Web infrastructure.

Click here for more of Dark Reading's Black Hat articles.

"We are at an inflection point," Peter Sheldon, an analyst for Forrester, wrote yesterday in a blog post. "With consumer adoption of HTML5-'capable' desktop browsers widespread and web developer understanding of the technology rapidly maturing, HTML5 is no longer an emerging toolset for mobile and tablet development. Instead, it is fast becoming the de facto standard for web experience innovation across touch points."

He says that leading brands, such as Apple, Best Buy, and Four Seasons Hotels, are taking advantage of advanced HTML5 to enhance customers' online experience, and that e-business teams within other enterprises need to leverage the specification for improved competitive differentiation. It needn't involve a wholesale rip-and-replace of existing code, as HTML5 is essentially an extension of existing W3C HTML standards, he explains.

"The decision to start using HTML5 or CSS3 does not require any changes to or throwing away of existing code," Sheldon said. "Instead, e-business teams can simply enhance the user experience of existing sites by incrementally using the new features of HTML5. HTML5 puts more tools in the box, but it doesn’t change the fundamentals of how to build the website."

If organizations are to do it right, though, one of those fundamentals needs to be a thorough secure coding process. As one Indian researcher highlighted at Black Hat recently, the rich capabilities afforded by HTML5 open up a whole new world of attack opportunities for hackers.

"HTML5 has lots of components that, if they are not securely coded, can cause a number of new attack vectors," said Shreeraj Shah, founder and director of Blueinfy Solutions. "By leveraging these vectors, one can craft stealth attacks and silent exploits [that are] hard to detect and easy to compromise."

He explained at the show that in many cases a full-fledged HTML5 site offers enough functionality that it could almost be likened to a small operating system running in the browser. With HTML5 it is possible to create sites that locally store small databases on the client. As he demonstrated in his talk, components like local storage, enhanced XMLHttpRequest (XHR), Document Object model (DOM), and webSQL that make advanced features possible greatly increase a user's attack surface if coded improperly.

In his talk, Shah ran through a number of different vulnerabilities and demonstrated proof-of-concepts for many, with all of them falling under three main categories.

1. XHR And Tag Vulnerabilities
The first, XHR and tag vulnerabilities, stem from enhancements to XHR in HTML5 that changes HTTP request and response to allow cross-domain calls by following what is called the Cross Origin Resource Sharing (CORS) policy. This change greatly enhances the potency of Cross Site Request Forgery (CSRF) attacks, enabling more stealthy CSRF attacks that can send CSRF on the raw stream of data from the browser and which can not only be sent with the request, but also sent back with the response.

"So it is like crosssite response extraction," he said.

Also in this category, Shah lumped in Cross Site Scripting (XSS) attacks that take advantage of the surfeit of new tags, attributes, and events offered up through HTML5.

"This is definitely an interesting attack vector to bypass an existing blacklist or whitelist because these are a whole new set of tags that can possibly cause XSS," he said.

2. Thick Feature Vulnerabilities
The next category of vulnerabilities Shah called out stem from the fat client functionality brought forth by HTML5. The support of local storage and session storage through HTML5's storage API makes it possible for attackers to use XSS to do blind enumeration of local storage variables and eventually get access to local storage. Similarly, if a local file system is created using SQL Lite to store a database locally, attackers can potentially run SQL injection attacks against that database through attacks leveraging blind WebSQL enumeration.

"So we are still dealing with SQL injection on the server side and now we have SQL injection on the client side using XSS," he said.

3. DOM Vulnerabilities
Finally, the third big category that Shah ran through were vulnerabilities around DOM.

For example, HTML5 now makes it possible for developers to create an HTML-5 based application that runs on a single DOM without any refreshes necessary. This is a boon for performance, but it also makes DOM-based XSS a "sleeping giant" in Shah's mind.

"Essentially, what is going to happen is when you have a DOM-based XSS, that XSS will remain throughout the application life cycle," he said.

In the same vein, HTML5's support of caching pages for offline usage opens the possibility of cache poisoning. And the way that the widgets, gadgets, and modules popular with HTML5 applications share.

As Shah noted in a paper written in conjunction with his talk, the vendor-neutral, browser-native nature of HTML5 is finally starting to gain the specification traction within developer communities. He noted that the attacks he detailed are just the tip of the iceberg because "HTML5 is just warming up."

As different libraries and ways of development continue to emerge, new attack surfaces are bound to come up. That is why Shah said he believes developers need to start thinking about these possible vulnerabilities from the outset of their HTML5 initiatives.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

'Hacking' 카테고리의 다른 글

Metasploit : Bind TCP ? Reverse TCP?  (1) 2012.11.06
Samsung Galaxy S III Hacking  (0) 2012.09.27
HTML5 Security & Mobile  (0) 2012.09.25
Burp Suite Tutorial – The Intruder Tool  (7) 2012.08.10
Understanding the iOS Security Architecture  (0) 2012.08.08
Posted by CEOinIRVINE
l

HTML5 Security & Mobile

Hacking 2012. 9. 25. 04:56

Last week, I discussed some of the new, exciting functionality that is available as part of HTML5 and how it applies to the enterprise.  While this new functionality presents several new opportunities to change how content and functionality is delivered to employees and customers, there are security and compatibility concerns that must be understood prior to embarking on a great HTML5 journey.
 
Today, we'll discuss some of the more common security concerns raised as part of the HTML5 specification as well as compatibility issues you may face while implementing some of the new HTML5 components.  In some cases, I'll include notes on how certain issues can be avoided.
 
Security
The new benefits of HTML5 aren't without their security concerns and potential for abuse.  Some of the concerns below may not be applicable for mobile apps deployed at the enterprise level, but worth reviewing nonetheless.
  • Web Storage: To the point, there are security concerns with client-side storage.  There is a large potential for abuse if not implemented properly. Here are some security concerns that should be reviewed as part of planning and design.  Keep this in mind while reading (credit toOpera for the verbiage), origin is the tuple of scheme/host/port.  Thus, http://captechventures.com, http://blogs.captechventures.com, https://captechventures.com and http://captechventures.com:80 are all different origins.
    • Storage is assigned on a per origin basis so DNS spoofing is possible which would allow intruders access to a users data. SSL can be used to prevent this.
    • While this will probably not be an issue in the enterprise (since Geocities has left us - moment of silence), Web Storage should not be used where more than one user is using different pathnames on one domain.  For example, if I implemented Web Storage at captechventures.com/nathan/ it would be accessible by captechventures.com/jones/ (note: not valid URLs).
    • Databases are stored locally, on the client, which allows would-be attackers to download a copy of your database and create very precise attacks by issuing plain SQL statements. There's no need to employ injection techniques when you have the database. While this may not immediately impact mobile devices (retrieving content from them is not straight-forward), proper security should be put in place - phone locks, data retention periods (e.g. if the new lead has been sent to the CRM system, wipe it from the local database), etc.
    • The fact that the database resides on the client also opens up the potential for attacks on your backend enterprise systems. Your schema is now widely known; very targeted, malicious queries can be created.  Proper consideration should be given to your mobile storage design - client-side storage should only store a small subset of what may be available at an enterprise level.  Therefore, design a new schema specific to that subset rather than deploying your enterprise design.  
  • Cross-Domain Capabilities: The new capabilities in HTML5 such as canvas, audio and video make it easy to access content across domains and continue to 'mashup' information.  However, this could introduce information leakage.  There are safe-guards being put in place to help prevent information leakage.  For example, the canvas element contains an attribute called origin-clean which indicates whether the content originates from a different origin (see Opera's explanation of origin above) or not.  If the origin-clean flag is set to false, calling the toDataURL() or getImageData() methods of the element would raise a SECURITY_ERRexception.
  • Geolocation: Geolocation presents a host of privacy concerns - you're pinpointing  the location of the device and therefore the user. While not always 100% accurate, geolocation should be used sparingly, requesting location information only when absolutely necessary to improve the user experience.  Proper warnings and terms must be included to make the user aware that you are storing location information and potential consequences.  Broadcasting that you're home (GPS coordinates included) once a day for months and then telling the world you're in Maui on vacation may have unfortunate consequences.
  • Forms: Javascript is client-side code and, as such, you lose a lot of control. While client-side validation, especially on a mobile device, can be powerful you should always validate form submissions server-side to ensure integrity.  Yes, this may require an extra round-trip, on occasion, but if someone has malicious intent, I wouldn't worry if they eat another 120KB of their data plan.
  • KeyGen: This is a post for another day, but HTML5 also includes the keygen element which facilitates the creation of private and public keys for identity verification - think enterprise security, banking, etc.  You should note that adoption is not standardized, documentation is sparse, and Microsoft has even asked that it be removed from the HTML5 specification all-together.  Here is one link I found useful if you're itching to dig deeper.
Compatibility
Creating a web-based version of a mobile application is quicker and typically more cost effective to deploy than platform native applications. Firstly, you don't need an in-house Objective-C developer and iPhone OS (iPad/iPod included) API guru, Java developer, and someone versed in thecumbersome Blackberry API's.  HTML5 web-applications, simplistically speaking, require a web developer and web designer. Secondly, you don't have a platform specific approval process to battle.  Consider the source, but even Google's VP of Engineering points out that not many companies are rich enough to build native apps in support of each mobile platform.
 
That being said, there are compatibility issues to consider when looking at HTML5 for your mobile application.  HTML5 is still in draft status and is not supported by all mobile browsers.  Mobile Safari (iPhone), the Android browser support quite a few, but not all, changes in the HTML5 specification.  Opera Mini supports some (currently, around 10%) but is constantly evolving and was recently approved for use on the iPhone. IE Mobile 6.0 still doesn't appear to have much support for HTML5.  I'm still researching what will be available as part of the new Windows Mobile version 7.0, but am not holding my breath.
 
Blackberry is beginning to implement some of the specification (e.g. the datalist element), in some of it's browsers but it's still not ready for prime time.  With multiple versions of their browser running on multiple versions of the OS, building for the Blackberry will be challenge. This has been heralded as one of the biggest obstacles for HTML5 to overcome in order to go mainstream.  In my humble opinion, as Android and the iPhone continue to gain market share, Blackberry will pick up the pace of innovation.
 
In the mean time, creating a lighter version for Windows Mobile and Blackberry, while frustrating, is an option.  Another potential option would be to deploy Opera Mini to your Windows and Blackberry devices. It runs on each platform and, while it only supports about 10% of the specification now, it is evolving. Remember, Opera was a core contributor to Web Applications 1.0.

If you're interested in discussing how CapTech can help mobilize your enterprise, contact Jack Cox, the Mobile Service Offering lead.


'Hacking' 카테고리의 다른 글

Samsung Galaxy S III Hacking  (0) 2012.09.27
HTML5 Top 3 Vulnerability  (2) 2012.09.25
Burp Suite Tutorial – The Intruder Tool  (7) 2012.08.10
Understanding the iOS Security Architecture  (0) 2012.08.08
Cydia Repositories  (7) 2012.08.05
Posted by CEOinIRVINE
l

  1. XSS
    1. Severity : High
    2. URI was set to 1<div style=width:expression(prompt(957586))>
      URL encoded GET input genre was set to " onmouseover=prompt(968437) bad="


  2. Application Error Msg
    1. Severity : Medium
    2. URL encoded GET input key was set to '"'");|]*{%0d%0a<%00>
      Error message found:
      java.lang.NumberFormatException: For input string:


  3. Error Msg on Page
    1. Severity : Medium
    2. Pattern found:
      java.lang.NumberFormatException: For input string:


  4. Insecure crossdomain.xm
    1. Severity : Medium
    2. The browser security model normally prevents web content from one domain from accessing data from another domain. This is commonly known as the "same origin policy". URL policy files grant cross-domain permissions for reading data. They permit operations that are not permitted by default. The URL policy file is located, by default, in the root directory of the target server, with the name crossdomain.xml (for example, at www.example.com/crossdomain.xml).

      When a domain is specified in crossdomain.xml file, the site declares that it is willing to allow the operators of any servers in that domain to obtain any document on the server where the policy file resides. The crossdomain.xml file deployed on this website opens the server to all domains (use of a single asterisk "*" as a pure wildcard is supported) like so:
      <cross-domain-policy>
      <allow-access-from domain="*" />
      </cross-domain-policy>
      
      This practice is suitable for public servers, but should not be used for sites located behind a firewall because it could permit access to protected areas. It should not be used for sites that require authentication in the form of passwords or cookies. Sites that use the common practice of authentication based on cookies to access private or user-specific data should be especially careful when using cross-domain policy files.
      This vulnerability affects Server.


'IT' 카테고리의 다른 글

worst companies to work for  (0) 2011.03.15
OSI Layers  (0) 2011.03.15
Intermediate CA Certificates Problem  (1) 2011.03.04
iPad 2 구매대행..  (0) 2011.03.03
Galaxy Tab vs. the iPad  (0) 2010.11.24
Posted by CEOinIRVINE
l

Amazon Seller XSS

Hacking 2010. 10. 20. 04:58
for example,
change-password/-"><iframe src="http://hackerssite.com">-.html
 
 

https://sellercentral.amazon.com/gp/change-password/-%22%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E-.html


The XSS bug affects the "Password Assistance" page, thus becoming the ideal phishing weapon for fraudsters who target sensitive personal and financial information. As you can view in the following screenshot, "See Me" injected an iFrame tag that retrieves the first page of XSSed.com. Instead, with border set to 0 in the tag, it could retrieve a deceitful seller central user login page that logs authentication credentials in cleartext and sends them to the fraudster's e-mail inbox.
 

 
Amazon is usually quick at remediating security issues affecting their online properties. Of course, they should go through a thorough source code security review and testing before they put stuff live.

'Hacking' 카테고리의 다른 글

What is the best way to manually test for buffer overflows?  (0) 2011.02.03
PT FrameWork  (0) 2010.12.17
FPS hack provider  (0) 2010.10.20
Hiding files using ntfs file streaming  (0) 2010.10.16
Back up Jailbreaked iPhone APPs  (0) 2010.09.21
Posted by CEOinIRVINE
l

XSS Cheat Sheet

Hacking 2009. 2. 6. 09:41

XSS (Cross Site Scripting) Cheat Sheet
Esp: for filter evasion


By RSnake

Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to mitigate XSS vectors or how to write the actual cookie/credential stealing/replay/session riding portion of the attack. It will simply show the underlying methodology and you can infer the rest. Also, please note my XSS page has been replicated by the OWASP 2.0 Guide in the Appendix section with my permission. However, because this is a living document I suggest you continue to use this site to stay up to date.

Also, please note that most of these cross site scripting vectors have been tested in the browsers listed at the bottom of the page, however, if you have specific concerns about outdated or obscure versions please download them from Evolt. Please see the XML format of the XSS Cheat Sheet if you intend to use CAL9000 or other automated tools. If you have an RSS reader feel free to subscribe to the Web Application Security RSS feed below, or join the forum:

Web Application Security RSS feed


XSS (Cross Site Scripting):
    XSS locator. Inject this string, and in most cases where a script is vulnerable with no special XSS vector requirements the word "XSS" will pop up. Use the URL encoding calculator below to encode the entire string. Tip: if you're in a rush and need to quickly check a page, often times injecting the depreciated "<PLAINTEXT>" tag will be enough to check to see if something is vulnerable to XSS by messing up the output appreciably:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    XSS locator 2. If you don't have much space and know there is no vulnerable JavaScript on the page, this string is a nice compact XSS injection check. View source after injecting it and look for <XSS verses &lt;XSS to see if it is vulnerable:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    No filter evasion. This is a normal XSS JavaScript injection, and most likely to get caught but I suggest trying it first (the quotes are not required in any modern browser so they are omitted here):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well - I'll probably revise this at a later date):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    No quotes and no semicolon:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Case insensitive XSS attack vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    HTML entities (the semicolons are required for this to work):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Grave accent obfuscation (If you need to use both double and single quotes you can use a grave accent to encapsulate the JavaScript string - this is also useful because lots of cross site scripting filters don't know about grave accents):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Malformed IMG tags. Originally found by Begeek (but cleaned up and shortened to work in all browsers), this XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. I assume this was originally meant to correct sloppy coding. This would make it significantly more difficult to correctly parse apart an HTML tag:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    fromCharCode (if no quotes of any kind are allowed you can eval() a fromCharCode in JavaScript to create any XSS vector you need). Click here to build your own (thanks to Hannes Leopold):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    UTF-8 Unicode encoding (all of the XSS examples that use a javascript: directive inside of an <IMG tag will not work in Firefox or Netscape 8.1+ in the Gecko rendering engine mode). Use the XSS calculator for more information:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Long UTF-8 Unicode encoding without semicolons (this is often effective in XSS that attempts to look for "&#XX;", since most people don't know about padding - up to 7 numeric characters total). This is also useful against people who decode against strings like $tmp_string =~ s/.*\&#(\d+);.*/$1/; which incorrectly assumes a semicolon is required to terminate a html encoded string (I've seen this in the wild):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Hex encoding without semicolons (this is also a viable XSS attack against the above string $tmp_string =~ s/.*\&#(\d+);.*/$1/; which assumes that there is a numeric character following the pound symbol - which is not true with hex HTML characters). Use the XSS calculator for more information:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Embedded tab to break up the cross site scripting attack:
    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Embedded encoded tab to break up XSS:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Embeded newline to break up XSS. Some websites claim that any of the chars 09-13 (decimal) will work for this attack. That is incorrect. Only 09 (horizontal tab), 10 (newline) and 13 (carriage return) work. See the ascii chart for more details. The following four XSS examples illustrate this vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Embedded carriage return to break up XSS (Note: with the above I am making these strings longer than they have to be because the zeros could be omitted. Often I've seen filters that assume the hex and dec encoding has to be two or three characters. The real rule is 1-7 characters.):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Multiline Injected JavaScript using ASCII carriage returns (same as above only a more extreme example of this XSS vector) these are not spaces just one of the three characters as described above:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Null breaks up JavaScript directive. Okay, I lied, null chars also work as XSS vectors but not like above, you need to inject them directly using something like Burp Proxy or use %00 in the URL string or if you want to write your own injection tool you can either use vim (^V^@ will produce a null) or the following program to generate it into a text file. Okay, I lied again, older versions of Opera (circa 7.11 on Windows) were vulnerable to one additional char 173 (the soft hypen control char). But the null char %00 is much more useful and helped me bypass certain real world filters with a variation on this example:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Null breaks up cross site scripting vector. Here is a little known XSS attack vector using null characters. You can actually break up the HTML itself using the same nulls as shown above. I've seen this vector bypass some of the most restrictive XSS filters to date:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Spaces and meta chars before the JavaScript in images for XSS (this is useful if the pattern match doesn't take into account spaces in the word "javascript:" -which is correct since that won't render- and makes the false assumption that you can't have a space between the quote and the "javascript:" keyword. The actual reality is you can have any char from 1-32 in decimal):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Non-alpha-non-digit XSS. While I was reading the Firefox HTML parser I found that it assumes a non-alpha-non-digit is not valid after an HTML keyword and therefor considers it to be a whitespace or non-valid token after an HTML tag. The problem is that some XSS filters assume that the tag they are looking for is broken up by whitespace. For example "<SCRIPT\s" != "<SCRIPT/XSS\s":

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Non-alpha-non-digit part 2 XSS. yawnmoth brought my attention to this vector, based on the same idea as above, however, I expanded on it, using my fuzzer. The Gecko rendering engine allows for any character other than letters, numbers or encapsulation chars (like quotes, angle brackets, etc...) between the event handler and the equals sign, making it easier to bypass cross site scripting blocks. Note that this also applies to the grave accent char as seen here:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Non-alpha-non-digit part 3 XSS. Yair Amit brought this to my attention that there is slightly different behavior between the IE and Gecko rendering engines that allows just a slash between the tag and the parameter with no spaces. This could be useful if the system does not allow spaces.

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Extraneous open brackets. Submitted by Franz Sedlmaier, this XSS vector could defeat certain detection engines that work by first using matching pairs of open and close angle brackets and then by doing a comparison of the tag inside, instead of a more efficient algorythm like Boyer-Moore that looks for entire string matches of the open angle bracket and associated tag (post de-obfuscation, of course). The double slash comments out the ending extraneous bracket to supress a JavaScript error:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    No closing script tags. In Firefox and Netscape 8.1 in the Gecko rendering engine mode you don't actually need the "></SCRIPT>" portion of this Cross Site Scripting vector. Firefox assumes it's safe to close the HTML tag and add closing tags for you. How thoughtful! Unlike the next one, which doesn't effect Firefox, this does not require any additional HTML below it. You can add quotes if you need to, but they're not needed generally, although beware, I have no idea what the HTML will end up looking like once this is injected:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Protocol resolution in script tags. This particular variant was submitted by Łukasz Pilorz and was based partially off of Ozh's protocol resolution bypass below. This cross site scripting example works in IE, Netscape in IE rendering mode and Opera if you add in a </SCRIPT> tag at the end. However, this is especially useful where space is an issue, and of course, the shorter your domain, the better. The ".j" is valid, regardless of the encoding type because the browser knows it in context of a SCRIPT tag.

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Half open HTML/JavaScript XSS vector. Unlike Firefox the IE rendering engine doesn't add extra data to your page, but it does allow the javascript: directive in images. This is useful as a vector because it doesn't require a close angle bracket. This assumes there is any HTML tag below where you are injecting this cross site scripting vector. Even though there is no close ">" tag the tags below it will close it. A note: this does mess up the HTML, depending on what HTML is beneath it. It gets around the following NIDS regex: /((\%3D)|(=))[^\n]*((\%3C)|<)[^\n]+((\%3E)|>)/ because it doesn't require the end ">". As a side note, this was also affective against a real world XSS filter I came across using an open ended <IFRAME tag instead of an <IMG tag:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Double open angle brackets. This is an odd one that Steven Christey brought to my attention. At first I misclassified this as the same XSS vector as above but it's surprisingly different. Using an open angle bracket at the end of the vector instead of a close angle bracket causes different behavior in Netscape Gecko rendering. Without it, Firefox will work but Netscape won't:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    XSS with no single quotes or double quotes or semicolons:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Escaping JavaScript escapes. When the application is written to output some user information inside of a JavaScript like the following: <SCRIPT>var a="$ENV{QUERY_STRING}";</SCRIPT> and you want to inject your own JavaScript into it but the server side application escapes certain quotes you can circumvent that by escaping their escape character. When this is gets injected it will read <SCRIPT>var a="\\";alert('XSS');//";</SCRIPT> which ends up un-escaping the double quote and causing the Cross Site Scripting vector to fire. The XSS locator uses this method.:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    End title tag. This is a simple XSS vector that closes <TITLE> tags, which can encapsulate the malicious cross site scripting attack:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    INPUT image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    BODY image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    BODY tag (I like this method because it doesn't require using any variants of "javascript:" or "<SCRIPT..." to accomplish the XSS attack). Dan Crowley additionally noted that you can put a space before the equals sign ("onload=" != "onload ="):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Event Handlers that can be used in similar XSS attacks to the one above (this is the most comprehensive list on the net, at the time of this writing). Please note I have excluded browser support from this section because each one may have different results in different browsers. Thanks to Rene Ledosquet for the HTML+TIME updates:



    IMG Dynsrc:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    IMG lowsrc:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    BGSOUND:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    & JavaScript includes (works in Netscape 4.x):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02] [NS4]


    LAYER (also only works in Netscape 4.x)

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02] [NS4]


    STYLE sheet:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Remote style sheet (using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE and Netscape 8.1+ in IE rendering engine mode. Notice that there is nothing on the page to show that there is included JavaScript. Note: With all of these remote style sheet examples they use the body tag, so it won't work unless there is some content on the page other than the vector itself, so you'll need to add a single letter to the page to make it work if it's an otherwise blank page:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Remote style sheet part 2 (this works the same as above, but uses a <STYLE> tag instead of a <LINK> tag). A slight variation on this vector was used to hack Google Desktop. As a side note, you can remove the end </STYLE> tag if there is HTML immediately after the vector to close it. This is useful if you cannot have either an equals sign or a slash in your cross site scripting attack, which has come up at least once in the real world:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Remote style sheet part 3. This only works in Opera 8.0 (no longer in 9.x) but is fairly tricky. According to RFC2616 setting a link header is not part of the HTTP1.1 spec, however some browsers still allow it (like Firefox and Opera). The trick here is that I am setting a header (which is basically no different than in the HTTP header saying Link: <http://ha.ckers.org/xss.css>; REL=stylesheet) and the remote style sheet with my cross site scripting vector is running the JavaScript, which is not supported in FireFox:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Remote style sheet part 4. This only works in Gecko rendering engines and works by binding an XUL file to the parent page. I think the irony here is that Netscape assumes that Gecko is safer and therefor is vulnerable to this for the vast majority of sites:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Local htc file. This is a little different than the above two cross site scripting vectors because it uses an .htc file which must be on the same server as the XSS vector. The example file works by pulling in the JavaScript and running it as part of the style attribute:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    List-style-image. Fairly esoteric issue dealing with embedding images for bulleted lists. This will only work in the IE rendering engine because of the JavaScript directive. Not a particularly useful cross site scripting vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    VBscript in an image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Mocha (older versions of Netscape only):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02] [NS4]


    Livescript (older versions of Netscape only):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02] [NS4]


    US-ASCII encoding (found by Kurt Huwig). This uses malformed ASCII encoding with 7 bits instead of 8. This XSS may bypass many content filters but only works if the host transmits in US-ASCII encoding, or if you set the encoding yourself. This is more useful against web application firewall cross site scripting evasion than it is server side filter evasion. Apache Tomcat is the only known server that transmits in US-ASCII encoding. I highly suggest anyone interested in alternate encoding issues look at my charsets issues page:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02] [NS4]


    META (the odd thing about meta refresh is that it doesn't send a referrer in the header - so it can be used for certain types of attacks where you need to get rid of referring URLs):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    META using data: directive URL scheme. This is nice because it also doesn't have anything visibly that has the word SCRIPT or the JavaScript directive in it, because it utilizes base64 encoding. Please see RFC 2397 for more details or go here or here to encode your own. You can also use the XSS calculator below if you just want to encode raw HTML or JavaScript as it has a Base64 encoding method:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    META with additional URL parameter. If the target website attempts to see if the URL contains "http://" at the beginning you can evade it with the following technique (Submitted by Moritz Naumann):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    IFRAME (if iframes are allowed there are a lot of other XSS problems as well):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    FRAME (frames have the same sorts of XSS problems as iframes):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    TABLE (who would have thought tables were XSS targets... except me, of course):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    TD (just like above, TD's are vulnerable to BACKGROUNDs containing JavaScript XSS vectors):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    DIV background-image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    DIV background-image with unicoded XSS exploit (this has been modified slightly to obfuscate the url parameter). The original vulnerability was found by Renaud Lifchitz as a vulnerability in Hotmail:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    DIV background-image plus extra characters. I built a quick XSS fuzzer to detect any erroneous characters that are allowed after the open parenthesis but before the JavaScript directive in IE and Netscape 8.1 in secure site mode. These are in decimal but you can include hex and add padding of course. (Any of the following chars can be used: 1-32, 34, 39, 160, 8192-8.13, 12288, 65279):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    DIV expression - a variant of this was effective against a real world cross site scripting filter using a newline between the colon and "expression":

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    STYLE tags with broken up JavaScript for XSS (this XSS at times sends IE into an infinite loop of alerts):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    STYLE attribute using a comment to break up expression (Thanks to Roman Ivanov for this one):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Anonymous HTML with STYLE attribute (IE6.0 and Netscape 8.1+ in IE rendering engine mode don't really care if the HTML tag you build exists or not, as long as it starts with an open angle bracket and a letter):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    IMG STYLE with expression (this is really a hybrid of the above XSS vectors, but it really does show how hard STYLE tags can be to parse apart, like above this can send IE into a loop):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    STYLE tag (Older versions of Netscape only):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02] [NS4]


    STYLE tag using background-image:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    STYLE tag using background:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Downlevel-Hidden block (only works in IE5.0 and later and Netscape 8.1 in IE rendering engine mode). Some websites consider anything inside a comment block to be safe and therefore does not need to be removed, which allows our Cross Site Scripting vector. Or the system could add comment tags around something to attempt to render it harmless. As we can see, that probably wouldn't do the job:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    BASE tag. Works in IE and Netscape 8.1 in safe mode. You need the // to comment out the next characters so you won't get a JavaScript error and your XSS tag will render. Also, this relies on the fact that the website uses dynamically placed images like "images/image.jpg" rather than full paths. If the path includes a leading forward slash like "/images/image.jpg" you can remove one slash from this vector (as long as there are two to begin the comment this will work):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    OBJECT tag (if they allow objects, you can also inject virus payloads to infect the users, etc. and same with the APPLET tag). The linked file is actually an HTML file that can contain your XSS:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Using an OBJECT tag you can embed XSS directly (this is unverified so no browser support is added):



    Using an EMBED tag you can embed a Flash movie that contains XSS. Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    You can EMBED SVG which can contain your XSS vector. This example only works in Firefox, but it's better than the above vector in Firefox because it does not require the user to have Flash turned on or installed. Thanks to nEUrOO for this one.

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Using ActionScript inside flash can obfuscate your XSS vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    XML namespace. The htc file must be located on the same server as your XSS vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    XML data island with CDATA obfuscation (this XSS attack works only in IE and Netscape 8.1 in IE rendering engine mode) - vector found by Sec Consult while auditing Yahoo:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    XML data island with comment obfuscation (this is another take on the same exploit that doesn't use CDATA fields, but rather uses comments to break up the javascript directive):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Locally hosted XML with embedded JavaScript that is generated using an XML data island. This is the same as above but instead referrs to a locally hosted (must be on the same server) XML file that contains your cross site scripting vector. You can see the result here:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    HTML+TIME in XML. This is how Grey Magic hacked Hotmail and Yahoo!. This only works in Internet Explorer and Netscape 8.1 in IE rendering engine mode and remember that you need to be between HTML and BODY tags for this to work:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Assuming you can only fit in a few characters and it filters against ".js" you can rename your JavaScript file to an image as an XSS vector:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    SSI (Server Side Includes) requires SSI to be installed on the server to use this XSS vector. I probably don't need to mention this, but if you can run commands on the server there are no doubt much more serious issues:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    PHP - requires PHP to be installed on the server to use this XSS vector. Again, if you can run any scripts remotely like this, there are probably much more dire issues:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    IMG Embedded commands - this works when the webpage where this is injected (like a web-board) is behind password protection and that password protection works with other commands on the same domain. This can be used to delete users, add users (if the user who visits the page is an administrator), send credentials elsewhere, etc.... This is one of the lesser used but more useful XSS vectors:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    IMG Embedded commands part II - this is more scary because there are absolutely no identifiers that make it look suspicious other than it is not hosted on your own domain. The vector uses a 302 or 304 (others work too) to redirect the image back to a command. So a normal <IMG SRC="http://badguy.com/a.jpg"> could actually be an attack vector to run commands as the user who views the image link. Here is the .htaccess (under Apache) line to accomplish the vector (thanks to Timo for part of this):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Cookie manipulation - admittidly this is pretty obscure but I have seen a few examples where <META is allowed and you can use it to overwrite cookies. There are other examples of sites where instead of fetching the username from a database it is stored inside of a cookie to be displayed only to the user who visits the page. With these two scenarios combined you can modify the victim's cookie which will be displayed back to them as JavaScript (you can also use this to log people out or change their user states, get them to log in as you, etc...):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    UTF-7 encoding - if the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following (Thanks to Roman Ivanov for this one). Click here for an example (you don't need the charset statement if the user's browser is set to auto-detect and there is no overriding content-types on the page in Internet Explorer and Netscape 8.1 in IE rendering engine mode). This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported. Watchfire found this hole in Google's custom 404 script.:
    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]




XSS using HTML quote encapsulation:
    This was tested in IE, your mileage may vary. For performing XSS on sites that allow "<SCRIPT>" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]+src/i":

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    For performing XSS on sites that allow "<SCRIPT>" but don't allow "<script src..." by way of a regex filter "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" (this is an important one, because I've seen this regex in the wild):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i":

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques but the only thing I've seen work for this XSS example if you still want to allow <SCRIPT> tags but not remote script is a state machine (and of course there are other ways to get around this if they allow <SCRIPT> tags):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    And one last XSS attack to evade, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" using grave accents (again, doesn't work in Firefox):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Here's an XSS example that bets on the fact that the regex won't catch a matching pair of quotes but will rather find any quotes to terminate a parameter string improperly:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    This XSS still worries me, as it would be nearly impossible to stop this without blocking all active content:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]




URL string evasion (assuming "http://www.google.com/" is programmatically disallowed):
    IP verses hostname:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    URL encoding:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Dword encoding (Note: there are other of variations of Dword encoding - see the IP Obfuscation calculator below for more details):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Hex encoding (the total size of each number allowed is somewhere in the neighborhood of 240 total characters as you can see on the second digit, and since the hex number is between 0 and F the leading zero on the third hex quotet is not required):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Octal encoding (again padding is allowed, although you must keep it above 4 total characters per class - as in class A, class B, etc...):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Mixed encoding (let's mix and match base encoding and throw in some tabs and newlines - why browsers allow this, I'll never know). The tabs and newlines only work if this is encapsulated with quotes:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Protocol resolution bypass (// translates to http:// which saves a few more bytes). This is really handy when space is an issue too (two less characters can go a long way) and can easily bypass regex like "(ht|f)tp(s)?://" (thanks to Ozh for part of this one). You can also change the "//" to "\\". You do need to keep the slashes in place, however, otherwise this will be interpreted as a relative path URL.

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Google "feeling lucky" part 1. Firefox uses Google's "feeling lucky" function to redirect the user to any keywords you type in. So if your exploitable page is the top for some random keyword (as you see here) you can use that feature against any Firefox user. This uses Firefox's "keyword:" protocol. You can concatinate several keywords by using something like the following "keyword:XSS+RSnake" for instance. This no longer works within Firefox as of 2.0.
    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Google "feeling lucky" part 2. This uses a very tiny trick that appears to work Firefox only, because if it's implementation of the "feeling lucky" function. Unlike the next one this does not work in Opera because Opera believes that this is the old HTTP Basic Auth phishing attack, which it is not. It's simply a malformed URL. If you click okay on the dialogue it will work, but as a result of the erroneous dialogue box I am saying that this is not supported in Opera, and it is no longer supported in Firefox as of 2.0:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Google "feeling lucky" part 3. This uses a malformed URL that appears to work in Firefox and Opera only, because if their implementation of the "feeling lucky" function. Like all of the above it requires that you are #1 in Google for the keyword in question (in this case "google"):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Removing cnames (when combined with the above URL, removing "www." will save an additional 4 bytes for a total byte savings of 9 for servers that have this set up properly):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Extra dot for absolute DNS:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    JavaScript link location:

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


    Content replace as attack vector (assuming "http://www.google.com/" is programmatically replaced with nothing). I actually used a similar attack vector against a several separate real world XSS filters by using the conversion filter itself (here is an example) to help create the attack vector (IE: "java&#x26;#x09;script:" was converted into "java&#x09;script:", which renders in IE, Netscape 8.1+ in secure site mode and Opera):

    Browser support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]


Character Encoding:
    All the possible combinations of the character "<" in HTML and JavaScript (in UTF-8). Most of these won't render out of the box, but many of them can get rendered in certain circumstances as seen above (standards are great, aren't they?):




Character Encoding Calculator

ASCII Text:

Hex Value:
    URL:


    HTML (with semicolons):


Decimal Value:
    HTML (without semicolons):

Base64 Value (a more robust base64 calculator can be found here)
    Base64:



IP Address:
    : dword level
Dword Address:
Hex Address:
Octal Address:


Browser support reference table:


IE7.0 Vector works in Internet Explorer 7.0. Most recently tested with Internet Explorer 7.0.5700.6 RC1, Windows XP Professional SP2.
IE6.0 Vector works in Internet Explorer. Most recently tested with Internet Explorer 6.0.28.1.1106CO, SP2 on Windows 2000.
NS8.1-IE Vector works in Netscape 8.1+ in IE rendering engine mode. Most recently tested with Netscape 8.1 on Windows XP Professional. This used to be called trusted mode, but Netscape has changed it's security model away from the trusted/untrusted model and has opted towards Gecko as a default and IE as an option.
NS8.1-G Vector works in Netscape 8.1+ in the Gecko rendering engine mode. Most recently tested with Netscape 8.1 on Windows XP Professional
FF2.0 Vector works in Mozilla's Gecko rendering engine, used by Firefox. Most recently tested with Firefox 2.0.0.2 on Windows XP Professional.
O9.02 Vector works in Opera. Most recently tested with Opera 9.02, Build 8586 on Windows XP Professional
NS4 Vector works in older versions of Netscape 4.0 - untested.

Note: if a vector is not marked it either does not work or it is untested.


Written in vim, and UTF-8 encoded, for her pleasure.
All rights reserved, all wrongs observed.
© 1995-2008 RSnake

'Hacking' 카테고리의 다른 글

SF Hacking (Purple Folder)  (1) 2009.02.10
How to be penetration tester? (Computer Security Specialist?)  (0) 2009.02.08
CIS benchmarks  (0) 2009.02.06
Below is a list of resources you've selected:  (0) 2009.02.06
Security Metrics  (0) 2009.02.06
Posted by CEOinIRVINE
l