This is mainly used as a helpful recon guide to determine what vulnerabilities are available to you as an ethical hacker or CTFer. I’ve spent quite a bit of time researching these vulnerabilities and spotting their telltale signs, and I hope to share them here. These are common or more unique vulnerabilities that I have seen, executed, and researched while doing CTFs.

Disclaimer: This article is not exhaustive, and is not intended to replace any research you would perform on your own. I merely present this as a guide to help others understand how exploits work, based on my own experience in CTFs and my research.

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS)

I group CSRF attacks and XSS attacks together because their attack delivery involves much of the same steps. CSRF attacks involve secretly invoking state-modifying requests, piggybacking on a victim’s sessional cookies (without them knowing), while XSS attacks involve rogue Javascript injection into a webpage to perform a variety of things. However, both involve the presence of some “victim”, who would need to visit a webpage that we control. If you suspect one of these exploits is available to you, look for specific areas where user-input is accepted, and for webpages that can be seen by other users. If your application satisfies both of those conditions, you can format your recon accordingly to look for these xss/csrf bugs.

SQL Injection

SQL databases are used for many different purposes - and most commonly in CTFs, they’re seen to authenticate users when logging in, or when searching through items displayed on a webpage (i.e you have a blog with a search function to look for a specific post).

If you see a login function, you can try to see if SQL injection can be at play by injecting rogue quotes ' in user input, or other SQL statements that could malform the underlying query in the backend (i.e '; -- which comments out the rest of the query). Be warned that by default, SQL exception errors are incredibly verbose, and CTF competitions may surpress these error messages to prevent a dead giveaway. You’ll typically want to log in as a privileged user, like admin.

If you see a search function through a collection, such as a collection of blog posts, the search may be using an SQL query to filter and display the database table accordingly. In CTFs, there may be a specific tuple in that query that is of importance, and which wouldn’t be seen by normal search terms. Injecting the appropriate queries in the search bar is just the same as when testing for SQLi in login functions - test if rogue quotes can be inserted, or portions of SQL characters that can malform the query underneath.

Local File Inclusion/Directory Traversal

Most commonly seen in applications developed in PHP, file inclusion vulnerabilities are a bit tricky to see unless you have an idea of what the source code looks like.

Anywhere that you can find a $file = $_GET[‘file’]; in PHP can be a giveaway for LFI attacks (though be careful - while most LFI attacks I’ve seen abuse PHP’s GET module, not all LFI attacks will use it). In more straightforward challenges, the problem may specify a file or hidden webpage somewhere on the server that can’t be accessed by a regular REST api, and so you may need to perform a directory traversal attack to move through the webserver’s directory in search of it.

SSRF

Also a trickier exploit to spot, SSRFs sort of look like CSRFs but instead of a user being tricked into making a request, a server is tricked. In simplistic challenges, I see this often as a website that checks URLs, so you input a URL and the site fires a GET request to it. SSRFs may require knowledge of the backend architecture to fully execute. Try and look for servers in an autonomous system that supports server intra-communication, and implements basic integrity checking (LAN checking, use of tokens, etc). See if there are any servers that are front-facing and can be communicated to.

XML External Entity (XXE)

XML parsers can be notoriously insecure, and a very prominent bug related to XML is external entity exploits - where you can specify the disclosure of sensitive files or the inclusion of malware in an XML file.

Look for where XML files are accepted into the application. If at any point, you can provide a .xml file to the server, there may be a chance for xxe.

HTTP Request Smuggling

While rare in CTFs, this is a unique bug that I wouldn’t mind seeing more exposure of in hacking competitions. Request smuggling requires communication between 2 servers that will process the same request differently (request parsers are notoriously not standardized). In your requests, look for feedback or other hints that a proxy server is in use, which typically reads through your request before sending it to the proper server. Furthermore, check to see if the multiple servers handle requests differently based on the Transfer-Encoding header and the Content-Length header in their responses.

Insecure Deserialization

Spotting deserialization bugs relies on the language used in implementing the application, as each language has a unique module or library for serialization purposes. If you have access to source code, look for known popular serial modules such as python’s pickle module, javascript javascript-serializer, etc etc. If not modules, look for class specifications, such as Java’s serilizable.io class, or functions like PHP’s serialize().

Deserialization bugs also take advantage of user input, so examine where in applications user input may be converted to some byte format for easy transportation. Looking out for specific formats, like JSON when dealing with Javascript applications, are important to note to see if they get passed through a deserializer.