When evaluating security issues or MRs, it can be useful to have a way to reproduce issues, dig in to root causes, look for further impacts. This can also be a great way to get familiar with GitLab during your first few weeks of onboarding. Here are some handy tips & tricks.
If you want to see the code executed as part of a web or API request, an interactive debugger may be a useful tool. Here's how to configure Pry & Thin
A typical workflow might be to find the
Controller action which kicks off the request (methods like
update are good bets), add in
binding.pry, save the file, then perform that request in a browser. The execution will stop and in a terminal you can inspect the current state using IRB, type
step to go in_to_ a method,
next to go to the next statement, and
continue to let the request run to the next break point and/or completion.
Watching logs can be helpful:
tail -f gitlab/log/development.log.
Your role might not require you to do "penetration testing", but having access to a testing proxy that lets you intercept and manipulate requests can help with reproducing HackerOne issues.
The AppSec team have a multi-user license for Burp Suite Professional. Ask in #sec-appsec about getting a license, and (download the latest stable version here). You can also use OWASP ZAP which is free and open source.
These tools can easily cause damage to websites or eat up your CPU with active scans. In OWASP Zap, use "Safe" mode to prevent any potentially malicious requests. In Burp Suite, disable any live "audit" scans.
When testing requires using multiple users, an Incognito / Private tab is an easy option. You can also create and use un-signed-in Chrome Profiles or Firefox Multi-Account Containers to provide "session sandboxes", which will persist beyond window closure (unlike Incognito tabs) and you can colour code them to help with visual distinction.