Software testing is an important part of software production. Whether done by the developer, a dedicated team of testers, or an army of volunteers, well-tested software helps to ensure that the end-user does not end up facing potential problems caused by software malfunctions.

There are also external testers who, without being formally enrolled as a volunteer, can also choose to help with testing the software. They may want to improve a product that they use themselves, or just for the fun of it, or in the hopes of a reward. And then there are the security researchers and ethical hackers.

Ethical hacking is not a shady job

Ethical hacking, also known as penetration testing, is testing a website or service for security flaws, for the purpose of improving the security of that website or service. This is the same as how a security researcher might perform testing of a deliverable software product, such as a browser.

The term "ethical hacker", however, relates to the testing of websites and services, and is a subcategory of security research.

Websites and Internet services are made from big and complex pieces of software. It is common to have small mistakes in them. A small mistake normally is not a problem - a web page might show an error message instead of the correct contents - but sometimes a mistake gives a hacker a way to make the website or product reveal secret information, show misleading messages, give access to accounts, or divulge large amounts of data held on the website.

Website owners try to ensure that they do not include any mistakes that can be abused this way, but occasionally, an important mistake will be missed. An example would be a login form on a website that allows you to try an infinite number of passwords so that you can log into an account. Another more serious example would be an SQL or command injection that does not sanitize quotes in a query string and will end up treating it as part of an SQL command or shell command.

Learn more about how we rate security issues.

Software applications (apps) are also often complex, and similar mistakes can happen. An app may be made to crash, or parts of the app could show an error. But it might also be possible to make it show incorrect security information or fail to update a security field. It might be possible to make it run executable code controlled by an attacker, or divulge private data.

Ethical hacking is a far cry from hacking

The term "hacker" originally meant someone who could apply advanced modifications to their computer's software configuration to change the way it works. However, when people say "hacker", they usually mean a person who has worked out a way to bypass the security of a website or service. That hacker then steals the data or gains access to accounts, and perhaps they will then cause damage that costs the company large amounts of money to repair. They may use tools for this penetration testing, or they may test it manually.

In the end, a criminal hacker may sell the stolen data, or details of the security issue itself, to malicious organizations for large amounts of money. Or they may use the stolen information directly for extortion, demanding money from victims.

An ethical hacker - or security researcher - will not steal any data, or cause any damage. Instead, they will report this issue to the website owner or product vendor, so that the owner can fix it.

Many website owners hire people specifically to perform this kind of testing so that they can improve the security of the website. Some website owners will openly invite ethical hackers to test their websites for issues. Some owners do not like having their websites or services tested in this way, and maybe hostile towards a security researcher, even though the security researcher is really trying to help.

An ethical hacker or security researcher chooses the high road

Why does an ethical hacker or security researcher choose a high road? Because many big website or service owners offer financial rewards for researchers that find exploitable issues and report them responsibly. For a good security researcher, this can be enough to earn a living. Smaller companies that are unable to afford a large budget might offer other rewards, such as merchandise, or the chance to have the researcher's name written on their website on a "hall of fame" credits page.

Learn more about Vivaldi's Security Hall of Fame.

Working to get your name on a website can help some fledgling security researchers to build their portfolio of work, and really helps when they are trying to apply for testing jobs. It is a badge of honor that can be carried around in the future.

However, this is essentially working for exposure and you should only do it if you feel that not getting financial compensation is right for you. This can be the case if you are doing this as a learning experience, only care about the credit or if you are really invested in getting the service or product improved.

If you would like to learn more about Vivaldi's security policies, and how Vivaldi rewards security researchers, take a look at our security pages.

Being a security researcher is not everyone's cup of tea

Security research appeals to a certain type of person who looks for small details and thinks about how that detail can be used in a bad way, but who has no bad intentions of their own. The type of person who might work in quality assurance and software testing.

Patience is very important because the work can be repetitive, and the chances of finding an exploitable issue might be low.

Several hours or days of work might end up revealing nothing important, or just present a lot of hope. The rewards are sometimes big, and sometimes small, so it helps to be someone who is happy with the small rewards and enjoys the feeling of success.

Most important is the ability to see the ways to misuse something. A feature that was meant to be used in a certain way, but if you use it in a different way, can you make something bad happen?

Programming ability helps for some things, for example, knowing the sort of mistakes a programmer is likely to make in specific languages. For websites, some programming languages might not offer a standard way to encode unsafe characters into HTML entities, so it might help to start looking for HTML injection issues with query strings that might allow cross-site scripting. PHP normally uses standard APIs to access MySQL-compatible databases, which send each query as a single statement, so even though the website might not sanitize SQL inputs, it might not actually be possible to use command splitting characters to run additional commands.

Being able to learn the protocols used by a service is a major plus. You might already have tools to test the password hammering protection for an HTML login form, but the website also offers POPaccount access, and you can study the POP3 protocol documents, and try programming your own tool to hammer the POP3 login password. The protocol is public, it's something you can learn from.

In some cases, if you don't have all of these skills, you might look if you can work as a team with people who can help in the areas where you are lacking. It can be powerful to have several people to discuss ideas with and at least one person who can deal with the parts of the process that require patience.

Get started with becoming a security researcher

There are plenty of articles out there already on the sort of common issues that can be found on websites. In fact, there is a very popular website run by The Open Web Application Security Project (OWASP) project, that many ethical hackers use as their guide, sharing details of the issues they have found.

Tools such as Burp Suite and Metasploit are used to automate testing. They will need some knowledge and configuration first, but they can perform many tests quickly without needing to do it all by themselves. Relying entirely on such tools, however, does not make you a good researcher, as the tools have their limits, and their responses need to be examined carefully.

For software apps, it is a little harder, since each application is different, and the sort of things that might be considered exploitable in one app might be considered irrelevant in another, depending on how they are designed to work. For all kinds of software, there are tools called "fuzzers" that send random junk input, or nearly valid but slightly wrong input, to the app or website, to see if it will malfunction. These require a little more knowledge, and in general, are something that would be used by the application developers.

Improving your security research

The simplest kind of testing can often be done with automatic tools, so large amounts of knowledge are not required. However, if you want to become really good at it, there are many universities around the world offering courses specifically for ethical hacking, and many for general security research. A common summer vacation assignment is to see how many website halls of fame you can get your name in.

In general, it is not really possible to use books for up-to-date information relating to potential exploits. Technology moves too fast, and books are out of date before they are even published. Online courses can often help keep you up to date, but this is a field where constant research is best.

Do's and Don'ts for security researchers

Not all security issues are "critical". They are definitely more important than regular bugs, but most have minimal impacts. Being able to apply the wrong stylesheet to a website is definitely not as important as being able to compromise all of the data on the server.

• Avoid assumptions: Do not assume that because a tool says it has found something, that it must be exploitable. Tools often warn about possible issues that can only be exploited in very specific circumstances, and the website or app might not satisfy those requirements; for example, a website might not have clickjacking protection, but that is not dangerous unless there is something harmful that can be done with a click.

• Investigate: Potential issues might need a lot of investigation first - the more of the work that you do, the more the website owner will want to reward you. If it is reported without testing if it can really be exploited, it wastes a lot of time both for the security researcher, and the website owner who has to explain to the researcher that their assumption is wrong. If you repeatedly report things too early without checking if they actually work as an exploit, the website owner can simply get upset with you and stop listening to your reports. Or they might choose not to reward you when you find a real issue because you have wasted so much of their time.
  Even though something is listed as being a security issue on The Open Web Application Security Project (OWASP), that doesn't mean that it is a security issue on the current website. The OWASP site mentions a lot of things that are totally irrelevant in most circumstances. For example, it has pages saying that revealing a server make or version number is dangerous because it lets an attacker know what issues to look for. This is not the case. A real attack uses all of the possible exploits without checking the make or version number. If it works, it works, if it doesn't then the attacker moves on to the next potential exploit. Hiding server make or version information just makes life harder for the security researcher, and only gives a false impression of security, known as security by obscurity.

• Not all issues are issues: When a website owner or product vendor has accepted that something is an issue, do not assume that it will always be an issue. Many website owners and vendors assume that being cautious is best. But some will actually investigate the real impact and might tell you correctly that what you have found is actually not an issue. The owner of the previous websites or products might have made the wrong assessment. Arguing might make the website owner or vendor stop listening to your reports.

• Report privately: Report things privately to the website owner or product vendor, and allow them a reasonable amount of time to fix issues. If you make the details public, you put the website or product and its users at risk, and you do not deserve the reward. If you share it with other researchers before the issue has been fixed, then the other researchers can reveal details, and you put the website and its users at risk. Issues cannot normally be fixed in a day, or a weekend, or over a vacation. Sometimes it might take a month or two to get all of the software updated. Keep communicating, and be flexible. This is how you earn your rewards.

• Check how to communicate reports: Before reporting the issue, check how the website owner or product vendor wants to receive reports. Technology companies often have dedicated bug reporting systems where reports can be made confidentially. Some use a security email address. Some might only have generic contact email addresses. Never, under any circumstances, report issues on public websites like Twitter, Facebook, Reddit, or forums. If that is the only way to contact a company, message them, stating that you have a security issue to report to them, and ask how to contact them in private.

• Evaluate ways to report: Reports almost never need a "proof of concept" video. As an example, with cross-site scripting, a simple link to the URL with the correct query string is enough. Videos are best used for complex cases where network requests need to be monitored, or interactions between different accounts need to be seen. For most issues, writing it in plain text is easier, even if you cannot write in the same language as the website owner or vendor. The website owner or vendor can use an online translation tool if needed. If you do choose to use a video, concentrate on the details of the issue itself, not on typing out your name or team or asking for rewards. Try not to waste time in the video, keep it short and simple. And make sure you never put your videos on a public website.

• Avoid Zero-Daying: If a website owner or product vendor refuses to listen or waits many months to fix simple issues, and you know that the issue is actually exploitable and very important, then sometimes it does help to disclose some minimal details publicly, to persuade the website owner to fix it. But this should be done only as a last resort, not a first resort. If you disclose it publicly too early, you put all the users of the website at risk, and you become as dangerous as a criminal hacker. Unfortunately, bad experiences with one company can make some researchers treat all companies as if they will be bad, and these researchers then insist on disclosing all issues they find elsewhere early, known as Zero-Daying. This is dangerous for everyone involved and does not deserve to be rewarded. Treat every company as if they will respond well, and give them a chance to respond.

• Develop credibility: Do not demand money before revealing information. This is not ethical hacking, it is extortion. That makes you a criminal hacker, not a hero. Do not ask for financial rewards in the first email, it can make you look like a criminal hacker. Companies that offer rewards will usually have it written in their security policies somewhere - if you are only interested in the money, then check before you test their site. Allow a company to check if your report is valid, and then see what they offer you. If your work is good, they will offer a reward if they have a rewards program. You don't need to ask.

• Seek permission: If you are going to perform testing that might look like a real brute-forcing or denial of service attack, ask for permission first. Otherwise, you will simply look like an actual attacker, and you will probably be treated like one. The website owners may already have software designed to detect such things, and it might ban you from testing again.

• Opt for honest research: If a website is using software from another company such as blogging software, server software, or forum software - and that software has a known security issue in it that was recently fixed, you do not need to tell the website owners unless they have left it a very long time. They will normally update it within a few weeks or months when they do their next software update. Reporting it to them in the hopes of gaining a reward is not really honest research. The researcher who deserves the reward is the one who found the original issue. If you want to earn the reward, look for new issues in the third-party software and report it to the vendor of that software, or look for issues in the website's own software.

Want to get involved?

At Vivaldi, we welcome security researchers who want to assist with the testing of our software. Do take a look at our security pages for more information.

On that note, we are very grateful to all of our software testers, both official and unofficial, for helping us to make great products for our friends. And to all of the security researchers who help to improve the security of our products and services, your contributions are very much appreciated.

Happy bug hunting!