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. This is the second part of the series, here we are going to discuss analyzing the web application. In the previous article, we had discussed . mapping contents 2. Analyze the Website Scan the Functionality We need to identify the main functionality of the website. Also need to indicate the actions that each function is created to perform when it is used. Find out the core security mechanics in the website and how it works. For example, we need to check how it works for authentication, season management, and access control and the functions that support them. Like user registration and account recovery. Know more about the peripheral functions like redirections, external links, error messages, admin and login functions. We should look for any functionality that is separate from the standard GUI activity, parameter naming, or navigation mechanism used in all the places on the website. We should check these ones by one for in-depth testing. Look Inside the Data Entry We need to see all the different entry points that accept user data inputs into the webserver. Also check the URLs, query string parameters, POST data, cookies, and other HTTP headers processed by the website. We inspect customized data transmission or encoding mechanics used by the website. Like a nonstandard query string. We need to understand where the data being submitted encapsulates parameter names and values. We need to identify any out-of-band channels through that user-controllable data or any other 3rd party data that is being introduced inside of the web server's processing. Like a webmail function will process and render messages received through SMTP. Know the Technologies Used We should identify each of the different technologies used in the website or web application. We will look for all the client-side technologies like forms, scripts, Java applets, cookies, ActiveX controls, and flash objects. If possible we should check the server-side technologies used on the server-side, like scripting language used, application platforms, and interaction with back-end components, like databases and e-mail systems. We also check the HTTP Server header returned in the website response. Also, we check the other functions identifiers contained within custom HTTP headers or HTML source code comments. Here different areas of the website might be used with different back-end components so different banners may be used. We need to fingerprint the website using the tool. WhatWeb We should check for interesting script names and query string parameters that may be from third-party code used. We can find them on Google using the qualifier to find any website using the same scripts and parameters. inurl: Mapping The Attack Surface We need to determine something about the internal structure & functionality of the server-side and need to know what kind of mechanism is running in the back-end. The idea should be taken from the visible side or client-side perspective. For example, if a function stores items in a shopping cart then it is most likely to be interacting with a database. For every function, we should identify and list the common vulnerabilities associated with each function. For example, file upload functions may be vulnerable to path traversal. User chat and forums may be vulnerable with XSS. Contact us functions may be vulnerable with SMTP injection. We should calculate an attack strategy, by keeping in mind the most serious vulnerable-looking functionality. We should use our plan to guide the amount of time and effort for each of our targeting sectors. End Notes This series of article is written of security and educational purposes. Please don’t misuse it. If anyone do any misuse then will be responsible for that. only he First get proper legal permission to test any website from the admin of that site. Or join any bug bounty program. The above methods will help us to analyze our target web application. Must read our previous part of this series “ ” - Mapping Contents. In the next part, we will test the client-side controls. A Guide To Web Security Testing: Part 1

Google

Target

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

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

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

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 1 - Mapping Contents

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 1 - Mapping Contents

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