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.
Many AppSec engineers will opt to install GitLab locally using GDK. Here's how to install GDK and how to use it. The UX team have a great summary of other ways to play with & test GitLab.
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 create or 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.
Some bugs require connecting to a service. An example is using ngrok to stub a fake GitLab server in "CVE-2022-0244: Arbitrary file read via the bulk imports UploadsPipeline".
Making your local machine accessible from the internet is not permitted, which precludes tools like ngrok or localtunnel. Use GitLab's Sandbox Cloud to host mock servers instead. Refer to Secure Cloud testing environments for advice on how to secure your Sandbox Cloud test environments.
