1. Introduction to BWAPP

buggy web Application, abbreviated BWAPP, is an open-source web application that packs in all kinds of common and recent vulnerabilities, with the goal of helping security enthusiasts, developers, and students find and prevent web vulnerabilities. It contains more than 100 vulnerabilities, covering every major known web vulnerability, including the OWASP Top 10 security risks, and most importantly it already includes the OpenSSL and ShellShock vulnerabilities.

2. Installing and Configuring BWAPP

BWAPP is a project written in php, so you need to set up a php + apache + mysql runtime environment locally. Installing apache, mysql, and php is beyond the scope of this post. One point worth making: under Windows, php depends on a specific VS library, otherwise it reports a dll loading error at runtime.

Copy all the BWAPP project files into php’s runtime directory, and modify the database configuration parameters in bwapp/admin/settings.php — you need to comment out $db_sqlite = “db/bwapp.sqlite”;. Run the bwapp/bWapp.sql file to create the bWapp database in MySQL and write the test data into it; this step can also be done by starting Apache and visiting http://localhost/install.php.

Finally, start MySQL and Apache and open http://localhost/portal.php in a browser, and you are in the environment where we will learn web penetration techniques — BWAPP.

3. How to Verify a Successful Penetration — A Popup Box

This is something you must consider before learning penetration techniques. How can you tell a penetration succeeded? Malicious hacking on the web comes down to roughly the following motives:

1. Curiosity. Trying out new techniques and probing system vulnerabilities; carrying out a penetration plan causes some loss, but not enormous harm. 2. Money. After penetrating, stealing user information and business system information, then using it as leverage for money or for trade, does great damage to a company. It could also be a hacking job paid for by a competitor. 3. Other. There are other reasons I will not enumerate one by one — for example, simply not liking the site ╭(╯^╰)╮, having been cheated by a website, planting js scripts for DDOS attacks, and so on.

All of these are achieved by executing some JavaScript script on a web page. The script can send the visitor’s Cookie to forge a login request, mount some popup images to trick users into clicking, launch a DDOS attack on a specified site, and perform any action that can be done on a web page.
The most critical part of a penetration is executing a piece of js code, so to verify a successful penetration you only need to prove that you successfully executed a piece of js code — for example, a popup box.

4. Common Penetration Principles and Applications

1. Reflected XSS: triggered by injecting and executing a script directly in the page.

For example: http://localhost/xss_get.php?firstname=aa%3Cscript%3Ealert(1)%3C/script%3E&lastname=aaa&form=submit

A reflected XSS attack embeds a javascript script directly in the url. For this kind of vulnerability, if the page has an input box, you can try entering parameters directly and watch how the url changes; if the input box content or the page text content changes along with the url, then you can be sure there is a reflected XSS vulnerability. Append < script >alert(1) < /script > after the url parameter and you will observe the popup. If the page has no input box, then you can only try appending parameters and scripts after the url.

Harm: commonly used to trick users into clicking a url and steal the information in their cookies.

2. Stored XSS: the injected script is written into the database, and the script only executes when the data is read and the page is accessed again.

For example, at http://localhost/htmli_stored.php, entering < script >alert(1) < /script > directly in the input box and clicking submit does not pop up immediately; instead it waits until the database is accessed again and the page is returned to the front end before the popup executes.

Stored XSS stores the executable script in the database, and on the next visit it is embedded in the page and executed. The key to analyzing this vulnerability is to find what information was entered and where that information is displayed. Look directly at the source code, find the html tag that contains this information, and close the html tag before the js script. The specific method is: for example, if you enter aaa and it shows up in the page source inside < a href=“aaa”>, then you can enter ">< script > alert(1) < /script >. Here, " closes the " symbol before aaa, and > closes the < in front of the a tag, so the html syntax definition is satisfied.

Harm: it not only steals the user’s cookie information, but also easily triggers a worm.

3. OS command and SQL injection: penetrate the system by closing the commands and SQL statements executed on the backend.

For example: http://localhost/commandi.php — entering www.nsa.gov|dir . in the input box. The intent of this command is to use the nslookup command to query the domain name’s IP address, but adding |dir . after the domain name makes the concatenation become nslookup www.nsa.gov|dir ., which is two command statements: first run the query task, then display all files in the current directory.

Services with web shells and sql concatenation need to watch out for this kind of attack. By closing a legitimate operation and then adding the symbols , : " & |, you chain on the hack command.

Harm: extremely dangerous — a single command like |rm -rf can bring the whole system down. When providing this kind of service, you must be careful to prevent it.

4. Man-in-the-middle attack.

For example: http://localhost/xss_stored_4.php — see another blog post, Burpsuite in Practice and Web Privilege Escalation Attacks, for the method of using BurpSuite to modify the part of the request about browser information, embed an executable script, store it in the database, and finally have it read and executed on the browser side.

Harm: the danger of a man-in-the-middle is that it is impossible to guard against — even with https, a certificate can be forged and the request and response messages modified. This kind of harm seriously leaks personal privacy; accounts and passwords can all no longer be guaranteed. But there is no need to panic: corporate websites will not be hijacked by a reverse proxy, and certificates cannot be forged without enormous computing resources. What you should guard against is not casually connecting to untrusted networks.