Security Cheat Sheet


Never try these on production deployments. Certainly don’t try them on third party sites as you could wind up in jail. This page is here to help people (i.e. myself) in coming up with techniques to try and test for security holes – in particular to remember some of the magic commands that I’ve used successfully during training courses.

This page will be frequently updated as I try and learn new techniques.

Note that I am not a pen tester. I just find like finding bugs and “security” is a great place to go look.

SQL Injection

This involves two parts that can be used in many ways.

  1. Escape the field, e.g. use characters ' or ".
  2. Insert your own SQL to change the result, e.g. skip a password check, break the DB or show more information than intended.

Note: Never try this against a site without permission.

Try and submit values into forms to skip authentication.

Lols’ OR ‘1’=’1SELECT * FROM users WHERE username=’<name>‘ and password = ‘Lols' OR '1'='1
Lols” OR “1”=”1SELECT * FROM users WHERE username=”<name>” and password = “Lols" OR "1"="1
MyUser’ —SELECT * FROM users WHERE username=’MyUser' --‘ and password = ‘<anyvalue>
-- ' and password = '<anyvalue>' is read as a comment.
This is effectively:
SELECT * FROM users WHERE username=’MyUser’

You can also try manipulating fields within URLs:

InjectionSQL command ranImpact
/users?status=1'--select * from users where status= ‘1'--‘ and hidden = 0Hidden users are listed due to the comment
select * from users where status= ‘1'; UPDATE users SET password='cake' WHERE username='admin'--‘ and hidden = 0A second SQL command is ran to set the password of a user.
select * from users where status= ‘1'; DROP ALL--‘ and hidden = 0A second SQL command is ran to drop the DB.

Speak to your developer about the database technology to learn more about the nuances in SQL.


Much like SQL injection, cross site scripting or XSS is about inserting malicious data into the application.

When performing testing it is easiest to just perform something simple and harmless like having an alert box pop up to say “XSS”. This isn’t much of an attack itself, but if you can do this, you’ve found an important bug.

  1. Look for where an application is outputting text that you’ve entered.
  2. First try using basic HTML tags like <b>Text</b> (bold) and seeing whether this shows up a Text. If it does, great.
  3. Try performing a script attack, e.g. <script>alert(‘XSS’)</script> or <script>console.log(1)</script>
  4. If that works, great! You’ve found a bug.

If your application is blocking script tags then there’s more that you can do. You could try to use body, image or link HTML tags, combined with events like “onload”.

You can also look at images where you type in a URL. For example lets say you have entered the URL ‘’ and see that the HTML to show your profile image is something like:

<img src="" width="100" height="100" />

Potentially we could hijack that image tag. So instead of the URL of your image, perhaps try:" /><script>alert("XSS")</script><img src="

What I’ve done there is end the tag myself, stuck in my attack then put in more HTML so that the page renders OK.

<img src="" /><script>alert("XSS")</script><img src="" width="100" height="100" />

Should you find an issue there are three types of XSS attack (note that names may vary):

  1. Self-executing attack where you can run javascript that only you see. Least of concern but still a bug.
  2. Reflected XSS attack, where you could share a URL with the attack.
  3. Permanent XSS attack, for example if you made it in a post, profile or some other place that is saved to the DB.

OS Command Injection

Remote OS Command injection is taking advantage of applications that are using your user input to run commands on the OS.

For example lets say the application is calling a script to do a bit of leg work: quantity productid

When we input a quantity of 5 and Product ID 84 into the web UI (or view Postman etc), it runs: 5 84

What OS command injection involves is putting some nasty commands into one of those inputs so that it ends up running another OS command.

For example if I input 84 & reboot, the application may run the following OS command: 5 84 & reboot

It may then calculate the cost as appropriate then happily reboot the server.

Basic “Go To” Commands

Providing these as inputs may introduce delays in responses that you can notice.

  • & ping -c 10 &
  • & sleep 10 &

The common command separators are &, &&, ;, | and || so you can try mixing up the above commands with different separators.

You could also try sticking a few common variables into your input and see if they are used (and subsequently give you info that you shouldn’t get)

  • –version
  • –help
  • $USER
  • $HOME
  • $ENV{‘HOME’}

URL Manipulation

Some web applications may believe that by simply not showing a link to an admin page might be enough to prevent users from accessing admin level functionality but access control permissions ought to be included within every page and every action.

Try guessing the admin panel URL. /admin,
/userpanel -> /adminpanel
Look for your user ID and modify it to access another user’s profile/editprofile?uid=123 -> /editprofile?uid=122
Spot user IDs in another URL then try and use that to override another page/viewfriend?user=122 and /editself -> /editself?user=122
Change actions in a URL/profilephoto/1234/view -> /profilephoto/1234/edit
Use bookmarks or tools like ZAP/Postman to learn URLs/API calls then repeat with another user.<too complicated to put as an example>

HTML & Chrome Dev Tools

Things to check via Chrome Dev Tools (CTRL + SHIFT + i)

  • Elements: Modify forms (change hidden fields, turn numbers to text, remove disable / required fields & look for elements hidden in CSS)
  • Console: TBC
  • Network: Look at headers in responses.
  • Network: Look for requests other than URLs. Any requests I can stick in Postman?
  • Application: Look at cookies. Stick values in decrypt/decode sites where possible.



See my Cheat Sheet of Cheat Sheets