In this detailed series of articles, we are going to discuss how to test a web application step by step. This is would be a long article but we divided it into parts, so . this will be a mega-series for web penetration testers and bug bounty hunters This article will cover all the categories of vulnerability and attacks an ethical hacker does while testing a website or web application. We are not giving guarantees that these methods will lead to unearthing vulnerabilities on a website, but it will give us a very good level of knowledge of how web penetration testing works. In this first part, we are going to look into the target website and try to know it. We are not just seeing it, we are going to watch our target very carefully, just like that we need to understand this article also very carefully. 1. Mapping Contents of a Website Scout Visible Contents First, we configure our web browser to use our favorite proxy intercept or spidering tool. For this we recommend but is also a good alternative. to passively spider the site and monitor and analyze the website's content through the proxy. BurpSuite WebScarab Sometimes it is very useful if we configure our web browser and use an extension like to check and parse the HTTP and HTML content processes. ZAP (OWASP Zed Attack Proxy) We can browse the website manually in a normal way. Visit each page and every link. We can try submitting forms and check it's processing. Browse the website or web application with JavaScript enabled and disabled, and with cookies enabled and disabled. If the website has user registration then we have or can create a login account to test its protected functions. When we browse the website we need to be aware of the requests and responses passing through our proxy intercept tool to understand how the data is being submitted and how the client is controlling the server-side application. We need to review the sitemap generated by our proxy intercept tool by the passive spidering. We look for that functionality or content that we have not checked through our browser. When we finished manually browsing and passive spidering, we can use our spider to continue actively crawling the website. This might sometimes uncover additional content that we overlooked when working manually. Information from Public Sources We can use search engines and archives (like ) to identify to identify what content the website indexed and stored. Wayback Machine We should use search engines' advanced options to get more improved results. Like on Google, we can use the site: to get all the content for our target, link: to get other sites linked to our target website. Sometimes, we can get old, removed content and get additional information. If we get any names, e-mail addresses, or phone numbers then we can search them on search engines. We specially focus on the forums if the target asked about any technical details there. That way we may get some information on infrastructure. We should review any published Web Services Description Language (WSDL) files to generate a list of function names and parameter values potentially employed by the website. Playing with Hidden Content First, we run some tolls like and to find hidden files and directories by using a brute-force attack on our target website. Bigger word lists will increase the chance of success. DIRB Gobuster We learn how the website/web application handles requests for non-existent items. We need to create some manual requests for known valid and invalid resources and compare the website's response to establish an easier way to know when an item doesn't exist We should create a list of all known files, links, and common file extensions. This will help us to guess the hidden files and directories. For example, if there are pages called then there is a high chance to have . AddDocument.jsp & ViewDocument.jsp EditDocument.jsp & RemoveDocument.jsp We should review all client-side codes to find any clues about hidden server-side codes or contents. We should check in HTML comments and disable from elements. We should understand the patterns from the client-side to the server-side processes. Find Default Contents To know about the webserver, we can run against it to detect what kind of server running. This may find any default or well-known in the server. We should use Nikto's options to increase its effectiveness. Like we can use flag to specify a directory to check default contents, flag used to specify a string that identifies a custom 'Not Found' page. Nikto --root -404 We should verify any juicy findings manually, it might be a false positive. We request the server's root directory, specifying the IP address in the Host header, and determine if the application responds with any different content. If it happens then we need to again run Nikto against the IP address as well as the server name. We should request to the server's root directory, specifying a range of User-Agent headers. Identify Identifier-Specified Functions We need to identify any instances where specific web application functions are accessed by passing an identifier of the function in a request parameter. We have discovered that the mechanism is being used to access individual functions. Like if the website uses a parameter that contains a function name, first we need to determine its behavior. . We should compile a list of common function names or cycle through the syntactic range of identifiers in use. Also, we can automate this task to identify valid functions as quickly & easily as possible. When an individual function is specified, and we should try to establish an easier way to identify when a valid function has been requested If needed & applicable we can compile a map of web application content based on the functional paths unlike the URL's, showing all the founded functions and the logical paths and dependencies between them. Testing the Debug Parameters We need to find some website's pages or functions where debug parameters are hidden, like . Maybe we find them in functions like login, search and file upload or download. debug=true We should make a list of common debug parameters like debug, source, test hide, and their common values like true, yes, no, and 1. On POST requests, we should check by submitting permutations of each name or value pair to each target. Try them on both in URL string and request body. We can automate this by using BurpSuite's Intruder (cluster bomb attack) to make a combination and permutations of two payload lists. We also check the application's response for any anomalies that may include that the added parameter had an effect on the website's processing. End Notes The above methods will help us to know much more about a target website. In the next part, we are going to go about analyzing our target website.

Google

Target

A Guide To Web Security Testing: Part 2 - Analyze the Web Application

Koushik Pal: 'Knowledge Should Be Free'

A Guide To Web Security Testing: Part 1 - Mapping Contents

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How to Create Your Own Dark Website (.onion) on Linux

#10 Rules of Bug Bounty

A Guide To Web Security Testing: Part 2 - Analyze the Web Application

Bounty0x Is Here To Change The Way People Make Money With Cryptos

Bug Bounties and Penetration Testing Will NOT Be Made Obsolete Anytime Soon.

How to Create Your Own Dark Website (.onion) on Linux

#10 Rules of Bug Bounty

A Guide To Web Security Testing: Part 2 - Analyze the Web Application

Bounty0x Is Here To Change The Way People Make Money With Cryptos

Bug Bounties and Penetration Testing Will NOT Be Made Obsolete Anytime Soon.

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps