Okay, Okay, Alright, Alright, I heard you! You must be looking for something more technical, not only just a story or journey. This is the last part which contains my methodology and resources that I found useful for anyone that currently planning and taking the AWAE.
Methodology
Everyone has to come up with the methodology that suitable for them to efficiently performing dynamic source code review (whitebox) assessment, especially on time-limited assessment such as OSWE exam. Below are the methodology that I found suits me:
1. Reduce the code size.
Modern web application utilized a lot of third-party modules or libraries that make the total line of codes sums up pretty huge. This can be surprising and overwhelming at first. Don’t worry too much on it, that’s just a noise. The code that really matters is not that much. You should not spend your time on reviewing the third-party modules and libraries. You can use grep -v command to exclude certain folders that containing the libraries from your grep command results.
2. Find the list of endpoints.
Every modern web applications supposed to have HTTP routing which defined what kind of function on the controllers got invoked whenever an endpoint is requested on the front-end application. For example on java you can grep for “RequestMapping” or “GetMapping” to find out the list of endpoints. Use this as your starting point of review.
3. Log is Love, Log is Life.
The log can be database log and application log. For vulnerability such as SQL Injection, the database log is the mandatory things to be enabled.
4. Align your focus with the objectives.
If the objectives is for you to bypass the authentication, you should not put your focus first on the authenticated part of the applications. You should focus on the menu or features that can be accessed by the unauthenticated users. If the objectives is to attain remote code execution, I usually start with top-down approach, meaning I start first with checking the interesting function on the web application, if nothing interesting comes up, I continue with the bottom-up approach where I grep for known dangerous function/code that can be exploited to get RCE.
5. Don’t trust the codes blindly, follow it through.
The code could be seen as it doing A, but eventually its doing Z. In this case, the debugging skill is really useful. Don’t trust the code blindly, use debugging to follow the code flow and understand why the code not doing what it supposed to do.
In the end, keep the Positive Mental Attitude. You probably have seen the vulnerability but just not yet noticing it. It got nothing to do with the lacks of your knowledge.
Resources
I think the most complete resources is the one compiled by Z-r0crypt on his blog: https://z-r0crypt.github.io/blog/2020/01/22/oswe/awae-preparation/
Other than that, you should check up the mr_me blog: https://srcincite.io/blog and see how awesome he is.
For practice, beside the OSWE new updated lab, I think you can try some of the whitebox vulnerable machine available on github. Personally, I didn’t yet have a chance to try it, but I think it worth to tried.
https://github.com/TROUBLE-1/White-box-pentesting
https://github.com/ScaleSec/vulnado