Buy me a tea

Secure code review

Secure code review is a systematic process that involves examining an application’s source code to identify and address security vulnerabilities.

Notes from my practice and the video of OWASP devslop with Vickie Lee here. I definietely recommend to check it out. It is really well explained.

Notes from OWASP DevSlop video

Tips from Vickie Lee. Watch the full video here. Examples will be taken from Tarpit-java

How to prep

Tools needed for manual code review

  • A good code editor or IDE. It is better if this tools:

    • Allows global searches across the code base

    • Allow regex searches

  • Scripting tools and a terminal (to create test and run experiments)

Prereqs

  • High level overview of how the app works

  • Where the important functionalities are

  • Who are the users

  • Who should be able to do what

  • Major frameworks and libraries

  • Add-ons and plugins used

  • What can go wrong (common vulns)

Code

Where to find code:

  • Client-side code

  • Desktop or mobile app source code

  • Leak code through a vulnerability (path traversal, etc)

  • OSINT: Github, pastebin, ...

  • Reverse the binary

Concepts

  • Source = Code that allows a vulnerability to happen

  • Sink = where the vulnerability actually happen

Example: Code injection. Source is where the user input is taken, sink is functions that execute arbitrary system commands.

IMG Source: Video from OWASP Devslop

Quick start hunting

How to find the most critical vulnerabilities fast

  • Search for known dangerous functions used on user-supplied input.

  • Search for harcoded credentials such as API keys, encryption keys, and db password.

    • Regex for AWS Access key ID "AKIA[0-9A-Z]{16}"

  • Search for weak cryptography or hasing algotrithm (grep on weak algorithm name)

  • Search for outdated dependencies (lots of vulnerabilities are introduced by 3rd party code)

  • Search for revealing developer comments (might contains sensitive infos)

Example Command injection

  • Look for a dangerous function such as eval(). In your code editor or with grep search for the string "eval("

For example in Tarpit-java:

It gets the user input from the request and use eval on it directly.

Example regex search on code base for hardcoded creds

In tarpit-java search for the following regex: "AKIA[0-9A-Z]{16}" (it will identify strings that start with AKIA that has 16 chars with the set we mentioned in the [] so from 0 to 9 and A to Z). This is actually what an AWS Access key would look like.

So in my Codium the search looks like this.

And we actually found a result:

More comprehensive review

  • Focus on critical functions first (authentication, Authorization, PII, etc)

    • anything that deals with sentitive data, payments shipping etc

  • Follow any code that deals with user input (see if they reach dangerous functionality)

    • Tracing the data flow

Example SQL Injection

In the file OrderStatus.java, we can see that a user input is taken for the variable orderId

String orderId = request.getParameter("orderId");

Later this string is used as is to request the database. So this is a SQL Injection.

String sql = "SELECT * FROM ORDER WHERE ORDERID = '" + orderId;

Use automation with manual analysis

  • Use tools and then manually verify the results.

Notes from my practice

General Methodology

It is possible to do manual grep for some classes. If the codebase is small you can read everything. It is wiser to install an ide. Usually in code review, you look for the sources first and see if there are sinks that are reachable, but often there is more code than time, so I prefer to cherry pick some sink that would be critical and look if there is a corresponding source. You can exclude the tests from a code review after checking if sensitive data like production secrets (password etc) are not stored in it.) When you don't have enough time it is interesting to review in 1 or 2 hours the summary of the ASVS (owasp appsec verification standard) to make corresponding greps. In general it is always important to follow the inputs and see where they go. We can also review bug patterns.

Dangerous functions in java

To avoid vulnerabilities like command injection or code injection exec(), eval()

File upload - check

  • Always check for unauthenticated file uploads

Enumerate entry points

thanks to my colleague Marc André for this one liner

  • grep -r -A2 -E '@(Get|Post|Put|Delete)Mapping' *

Tools

Spotbugs

On a Unix, Linux, or macOS system, run the $SPOTBUGS_HOME/bin/spotbugs script, or run the command java -jar $SPOTBUGS_HOME/lib/spotbugs.jar to run the SpotBugs GUI.

Other tools

  • SemGrep

  • FindSecBugd (analyse dynamique)

  • EsPReSSO plugin burp for oAuth: will analyze and describe communitcation with oAuth

List of weaknesses to look for

  • Hardcoded credentials or secrets (grep on "password", "key", "secret")

  • Information leak

  • Missing security flags

  • Weak password hashing mechanism

  • Cross-Site Scripting

  • No CSRF protection

  • Directory listing

  • Crypto issue

  • Signature bypass

  • Authentication bypass

  • Authorization bypass

  • Remote Code Execution

  • Grep on comments

  • Grep for file upload functionalities "upload"

Useful linux commands

  • curl "https://target.com/" | grep -oP '(https*://|www\.)[^ ]*' Extract all URL from Source Code (thanks Savan Patel on Linkedin for this command)

  • send curl to proxy export https_proxy=http://127.0.0.1:8080

  • Curl for multipart form data

  • Grep is a very convernient linux command to search for string. Learn more about it here

Resources

PreviousATMNextWeb Application and API Pentest Checklist

Last updated