All the attack techniques we described so far involved interacting with a live running app and have largely consisted of submitting the crafted input to the application and monitoring its responses. We will now examine an entirely different approach. We will review the application’s source code!
There are a lot of apps which use the open source, or even are the open source, so for those it may be possible to perform a source code audit to help attack a target web app. But that’s not all. Also, if you’re performing a penetration test in a consultancy context, the app owner may grant you the access to his source code for maximizing the effectiveness of your audit. There is so much more, but you will hear it in the further text. So, let’s go!
Approaches to Code Review
Taking a variety of approaches for carrying out a code review to help maximize your effectiveness in discovering the security flaws within the time that are available is what you can do here. Also, you can integrate your code review with the other test approaches to leverage the inherent strengths of the each.
We will talk about white-box code review here. Performing it, it can be a highly effective way to discover vulnerabilities within the application. So it is often possible with the access to source code to quickly locate the problems which would be extremely difficult or even time-consuming to detect using the black-box techniques.
Code review methodology. Almost every functional app is likely to contain many thousands of lines of source codes and in the most of the cases the time available for you to review it is likely to be restricted. So what is the key objective of the effective code review then? You need to identify as many security vulnerabilities as possible, given a certain amount of time and effort. What is this methodology all about then? Let’s show it on a list!
1.Tracing user-controllable data. It traces it from entry points into the application and reviews the code which is responsible for processing it.
2.Searching the code base for the signatures. Those signatures may indicate the presence of common vulnerabilities and review those instances for determining whether an actual vulnerability exists.
3.Performing a line-by-line review. This is for the inherent risk code to understand the app’s logic and find any problems which may exist within it.
Signatures of Cross-Site Scripting
A fairly constant signature within the database means that you can normally identify a good portion of the application’s vulnerabilities by quickly scanning and searching the codebase. Here we have cross-site scripting we already talked about, SQL injection, also known to us, path traversal-it has the signature which involves user-controllable input which is being based on a filesystem API without any validation of the input or verification that an appropriate file has been selected.
Furthermore, there is the arbitrary redirection, which is also known to us and we talked about it in the previous lessons
Perl
We will now describe the ways to acquire user-supplied input and the ways for interacting with the user’s session.Here we have the potentially dangerous APIs, and also security-relevant configuration options on the Perl platform.
This is the notorious language which allows the developers to perform the same task in a multitude of the ways. There are numerous Perl modules which can be used for meeting the different requirements.
Configuring the Perl Environment
The Perl itself provides a taint mode which helps prevent user-supplied input from being passed for the potentially dangerous functions. A program which is running in taint mode allows the interpreters tracks for each item of input received from outside the program and treat it as tainted. Such variables cannot be passed to a range of the powerful commands. If someone wants to use the tainted data in sensitive operations, that data must be cleaned by performing a pattern-matching operation and extracting the matched substrings.
This mode mechanism is actually designed for protection against many kinds of vulnerabilities, but it is effective only if the developers use appropriate regular expressions when extracting data from the tainted input. If it is too liberal and extracts the data it may cause many problems in the context in which it will be used. Also, then the taint mode protection fails, and the app still stays vulnerable.
I hope you have enjoyed our lesson today! It is not long but is important for you to understand and incorporate in your knowledge everything we have said. There are many people who have substantial experiences with testing the web applications interactively and exhibit an irrational fear of looking inside an app’s codebase for discovering the vulnerabilities directly. That fear is, we may admit, understandable for who are not programmers. But also, it is rarely justified. Any person that is familiar with dealing with the computer actually can, with a little investment, of course, gain sufficient knowledge and the confidence for performing an effective code audit. Do you want to be that person? Are you reading this because of that?
So, what would be your objective in audit then? It will be reviewing the app’s codebase. Besides that, you can aspire to understand some of the key processing that the app performs on the user-supplied input and to recognize some of the signatures which point toward the potential problems. In this case, the code review can be an extremely useful complement to the more familiar black-box testing.
Keep reading and keep following the news, and also visit the most relevant cyber security tips and interner security tips! Always search for more and from the best sources!