How many of you, developers, are aware of the impact of comments in the source code? How many of you, testers, check the pages source code during software testing? As a trainer of security courses I met a lot of testers and developers that are not aware of the value of comments in the source code. In this post I will share some insights and tips. With these you’ll have a better focus on the result, you’ll take the responsibility you have to take and, last but not least, testing becomes more fun.

First of all an easy, but important question. Do you as a tester check the source code of a page? Do you know how this works?

It is very easy, Right (most of the time) mouse click in a page -> show  source/source code/View Page Source.

Fig. 1: Right mouse click

The comments developers made in the code are in the GUI not visible. But if you look into the page source you can see them. From this point the treasures with the name comments are not hidden anymore but visible for everyone. As you can see in images below are the comments often shown in a different color.

At a high level there are two kinds of treasures hidden in the source code of a page.
The first are the comments in the source. There are a lot of possibilities in this group. Everything the developer want to make comment can be comment.
The second are the validations that are implemented on the client side. These one are interesting for avoiding for example field validations. These validations work fine if you only use the browser. But in case of using tools that can work around these validations they don’t have any value. Therefore they must be implemented on the server side.

Comments
A lot of developers use comments in the code to structure it, or to give other developers useful information if they have to work on their code.
They use for example:      “//for single line comments”
and    “/* This is a multiple line comment */”

During the security scans I did, I saw a lot of different comments in the code:

• Admin usernames and password combination
• Database references, table and column names
• Menu items, that are disabled
• Interesting text about defects that are solved
• Special codes that give you a reduction if you buy products
• Numbers like office number, userID’s that give you part of the code to access the application
• And much more…

Fig. 2: Disabled menu item

Fig. 3: Username and password in the source

This information is very useful for me as a tester to explore the application in a better way.  But hackers also love this information to enter your application as, for example, an administrator. Even if you have, in this case, a proper logging that register the users in the application, you don’t see any remarkable things because the admin is using the application with maximum of rights and he is allowed to do this.

Validations
The second category is totally different from comments in the code, but can also be found in the source code of a page. These are the validations that take place in the browser at the clients computer.

Tip: Be aware that validations that take place only at the client side are validations for usability and give the end user a quick response. For example about the format of a postal code, with such a client side validation it isn’t needed to send a request and response to the server to check the format. You get your feedback immediately.

But a tester or hacker can easily avoid these checks. If a request has left the browser, intercept is,  an change it the way you want. Intercept the message with for example WebScarab and order -1 book instead of 1 book, receive the book and earn money.

Some possible validations that take place at the client side are:

• Check at format, postal code, date of birth
• Check at length, for example maximum length is 4 (disable this validation and see what happen at the back end really nice to do in a test environment)
• Validation of the userID is in a certain range of numbers, disable this an log in with all ID’s
• Check a character set, only numbers for example see what happen if you fill fields with “@#$%ADer”
• And much more…

As you can expect these validations are meant to be in place in the browser. Delete or avoid these validations has an impact on the server side if they don’t take place there. In my opinion: If a tester takes the responsibility he has to take, you must test what happens if you disable the validation, explore this treasure!

And developers, be aware of these type of validations, they work fine for usability but are no security measure!

Doing these checks manually can cost a lot of time and effort, if you have to check each page, but it is worth it!

Automate the exploration
Automate the exploration with the use of a proxy tool. There are a lot of proper tools that identify for you the comments and validations in the page. WebScarab for example is one of these. In the main screen it show`s you two columns. One of them is the indicator of the comments in a page. The other one is the indicator for possible scripts.

The steps to see the scripts and comments:

1)    Browse in a webpage, while the traffic is configured through WebScarab.
2)    Go the WebScarab summary tab, and search for a page that is marked for comments an scripts
3)    Right click show comments, or show scripts
4)    Now you see the comments, you can easily change these comments. Check the meaning of a certain comment, for example and extra menu item.
5)    Make this menu item active by intercepting the response in WebScarab, delete the characters that make a certain part of the code comment.
6)    Check your browser, now you will see an extra menu item.

Fig. 4: Step 2, In the summary tab, 2 important columns

Fig. 5: Step 3, Show comments, show scripts

Fig. 6: Step 5, Delete comment

Fig. 7: Step 6, New menu item, left after, right befor

The same steps can be done for validations on the client side.

Some Tips

• Developers: comments in the source code are visible for everyone. They are not hidden an can be used by hackers for example.
• Developers: Validations only at the client site are no validations but usability mechanisms, people can easily avoid them.
• Testers: the complete source of a page is in scope of your test. Be aware of this. If you give an overview and insight in the quality, you can’t miss these.
• Testers: searching to these comments and validations is fun, it gives you new features and opportunities in the page to explore and (mis )use