There is usually a lot of debate about the use of manual and automated testing. Manual testing is often considered less reliable because it relies solely on the efforts of the test engineer. Automated testing, on the other hand, involves the use of multiple external tools, programming knowledge, and computing power, which seems more impressive and therefore more reliable.

Wrong! Discussing these two approaches as "manual versus automated" is a mistake, since both have different goals, different methods, and different advantages, especially when it comes to security testing.

Security testing is the assurance that the information you collect, process, and store on your website is securely protected from theft or leakage. Hackers have a variety of tools and techniques to attack web applications. The QA engineer's task is to stay one step ahead and ensure that the web application is able to withstand such attacks.

To do this, the QA engineer must mimic a hacker, trying as many attack approaches as possible to find vulnerabilities where an attacker can bypass the site's defenses.

In security testing, the balance between manual and automated testing is extremely important.

Manual Security Testing: XSS and SQL Injection

In manual security testing, the QA engineer must try to break the system manually by analyzing documentation and any other available sources of information. Their main task is to ensure that:

• The user cannot unintentionally disrupt the system.
• A hacker without any additional tools cannot cause serious problems.

There are two main types of attacks that can be carried out manually: XSS (Cross-Site Scripting) and SQL injection. Both of these attacks require a more detailed description.

XSS Injection

Cross-site scripting, or XSS, is the injection of malicious scripts into web pages through contact forms, registration forms, search fields, or any other input forms. When these scripts are executed by the browser, the attacker gains access to cookies, tokens, or any other sensitive information that was transmitted during the session.

For example, a hacker can inject a script that forces the user to navigate to another web page after clicking on an image:

http://test-site.com/search.php?q=<script>document.cookie</script>.

The script steals the cookies of the logged-in user.

An attacker can send an SQL query that can modify, delete, or copy data stored in the database. If your registration or login form has proper validation and the database queries are error-free, your database is safe. However, even a tiny error can make data vulnerable. The QA engineer's task is to check how resilient the application is to such attacks.

Consider an example of SQL injection:

SELECT * FROM Users; DROP TABLE Customers

These are two queries placed in one line separated by a semicolon, meaning they can be executed sequentially. As a result, a list of users will be displayed, and the Customers table will be deleted. Such a simple injection can cause significant damage to a business.

How to Prevent SQL Injection?

In fact, SQL injection vulnerabilities are fairly easy to avoid. Simply follow these steps:

• Use parameterized database queries. This allows the database to distinguish code from data and block SQL injection.
• Use stored procedures to process data.
• Use whitelist input validation. This approach prevents the user from entering data in a format other than expected.

If none of these options are feasible, then user input should be avoided. However, this trick is not a "silver bullet" for protecting a web application from all SQL injections.

Other Vulnerabilities Detectable Through Manual Testing

Along with various types of injections, other vulnerabilities are easily detected during manual testing.

Sensitive data exposure occurs when data is stored or transmitted unencrypted. This vulnerability can be detected manually by auditing cookies, tokens, and database records. To protect sensitive data such as passwords, banking information, etc., from disclosure, encryption and access control must be used.

Insecure direct object references - a vulnerability that allows a hacker to bypass authorization by entering modified parameter values. A test engineer can gain direct access to any piece of information by directly pointing to it, meaning an attacker can also do so, so the vulnerability should be fixed.

Broken authentication. For each valid session, the website creates a session cookie and session ID containing sensitive information such as username, password, etc. When the session ends, these cookies should be invalidated, otherwise this data will be stored in the system. When using a shared computer, there is a risk that login data may become accessible to other users. Such a vulnerability is easy to detect manually.

Automated Security Testing

In most cases, it is impossible to conduct a security audit of an application manually. This method gives access to only very limited types of vulnerabilities. But most of them are hidden deeper. To identify some issues in website security, it is necessary to intercept data channels, gain remote access to a computer, subject the system to heavy DoS/DDoS attacks, etc. Performing these actions manually takes too much time and effort, and in most cases is not even advisable, since a specialized tool can perform an automatic audit of the application.

To protect a web application at a deeper level, vulnerability scanners are needed. These tools scan the application code and find vulnerabilities that may be missed during manual testing.

Conclusion

Most website owners are not even aware that their web application is vulnerable until the threat becomes real and an attacker gains access to sensitive data. To predict and prevent possible attacks, security testing exists.