HACKING WEB APPLICATIONS - THE ART OF HACKING AND PENETRATION TESTING COURSE | hackin5min.com | HackingCourses

Hacking Web Application Course 

                The web application penetration testing is the popular among the Ethical 

Hackers because the Ethical hackers can pentest the web application that are in 

Bug Bounty Programs and can Earn Bounties and rewards 

HACKING WEB APPLICATIONS - 

THE ART OF HACKING AND PENETRATION TESTING COURSE | hackin5min.com | HackingCourses

Course of Contents:

Basically a web application is broken up into several components. These components are a web server, the application content that resides on the web server, and typically there a backend data store that the application accesses and interfaces with.

 This is a description of a very basic application. Most of the examples in this book will be based on this model. No matter how complex a Web application architecture is, i.e. if there is a high availability reverse proxy architecture with replicated databases on the backend, application firewalls, etc., the basic components are the same.

The following components makeup the web application architecture:

■ The Web Server

■ The Application Content

■ The Datastore

The Web Server

The Web Server is a service that runs on the computer the serves up web content. This service

typically listens on port 80 (http) or port 443 (https), although often times web servers will

run on non standard ports. Microsoft’s Internet Information Server and Apache are examples

of web servers. It should be noted that sometimes there will be a “middleware” server, or

web applications that will access other web or network applications.

*********************************************

Most web servers communicate using the Hyper Text Transfer Protocol (HTTP) context

and requests are prefi xed with “http://”. For more information about HTTP please refer to

RFC 2616 (HTTP 1.1 Specifi cation) and RFC 1945 (HTTP 1.0 Specifi cation).

Ideally web applications will run on Secure Socket Layer (SSL) web servers. These will

be accessed using the Hyper Text Transfer Protocol Secure (HTTPS) context and requests

will be prefi xed with “https://”. For more information about HTTP please refer to RFC

2818 (HTTP Over TLS Specifi cation). (We’ll cover hardening a Web server

The Application Content

The Application Content is an interactive program that takes web requests and uses

parameters sent by the web browser, to perform certain functions. The Application

Content resides on the web server. Application Content is not static content but rather

programming logic content, or content that will perform different actions based on

parameters sent from the client. The way the programs are executed or interpreted vary

greatly. For example with PHP an interpreter is embedded in the web server binary, and

interactive PHP scripts are then interpreted by the web server itself. With a Common

Gateway Interface (CGI) a program resides in a special directory of the web server

The Data Store

The Data Store is typically a database, but it could be anything, fl at fi les, command output, basically anything that application accesses to retrieve or store data. 

The data store can reside

on a completely different computer than the web server is running on. The Web Server and the Data Store do not even need to be on the same network, just accessible to each other via a network connection.

XSS Attacks and Checklists

Sometimes we forget about different things such as the difference between SQL queries in Oracle and SQL queries in MySQL, or maybe even the various DOM differences that exist in modern browser implementations. This can turn out to be a catastrophic experience, especially when you are on-site and you don’t have access to the Internet. 

One of the most useful features CAL9000 has to offer, is the number of references that we can check right from the main tool interface.

CAL9000 includes RSnake’s XSS Cheat Sheet, various other cheat sheets on topics such as Apache, Google, HTML, JavaScript, JSP, PHP, MySQL, Oracle, XML, XSLT, and so forth, and a useful checklist that we can use to ensure that all security aspects of the Web applications

*********************************************

Fuzzing

The third phase of testing is fuzzing which is the actual “hacking” phase. Once you have noted how the application works and identified all of the parameters being passed back and forth, it is time to manipulate them to try to make the application bend to your will. 

During this phase you will perform what is known as “fuzzing”. Basically this is the process of modifying parameters and requests being sent to the application and observing the outcome.

There are many open source and commercial tools that attempt to “automate” this step.

In some cases, these tools are good at finding specific examples of specific types of vulnerabilities, but in some cases they are not. In no way should an automated tool ever be solely trusted as the source for determining the overall state of security for an application.

It should be noted however, that running automated tools will help the overall.

Do not perform this phase of testing willy nilly as “fuzzing” can have disastrous

consequences, especially if you are performing an assessment of a production application.

It is highly advised not to run fully automated fuzzing tools in production environments.

It is best to think of yourself as a scientist. When you approach testing a function of the application, fi rst form a hypothesis. Then create a test case to validate your hypothesis. 

For example in a multi user multi role environment, for a specifi c test you would form a hypothesis that it is possible to perform administrative functions as a regular user. Then create a test case, in this case by logging into the application as a regular user and attempting to access the administrative functions. Based on the results of the test, you will either validate that it is possible for a regular user to access administrative functions or you will find that you need to modify the test in some way to gain administrative access or ultimately concede

that the application does not allow regular users to perform administrative functions under any circumstances.

If a vulnerability is found it is important to re-validate it. Once the vulnerability is identified it is important to document it. When documenting the fi nding it is important to include the full request that was sent to the server the resulted in the vulnerability.

Also note the user you were logged in as and what steps led you to the point that you were able to exploit the vulnerability. This is important information and will aid developers in reproducing

How you were able to exploit the condition which will help them in fi xing the problem.

During the second phase of testing you will want to look for all of the vulnerabilities that are described in this book. Vulnerabilities typically fall into categories with common root cause. 

For example the root cause of input validation issues can result in Cross Site

Scripting, SQL Injection, Command Injection, Integer Overfl ows, Buffer Overfl ows, etc.

                                        

               This course covers the complete Web application pentesting from beginner to advanced and Introduction to finding and hunting Bugs like Sql injection , Cross site Scripting , Html Injection , PHP Injection and Other Exploitation

*********************************************

HACKING WEB APPLICATIONS - 

THE ART OF HACKING AND PENETRATION TESTING COURSE | 

hackin5min.com | HackingCourses

Share Share Tweet Share Share Share

Click Me

DONATE VIA PAYPAL Support | | Contibute To Community https://hackin5min.blogspot.com/. Jai Hind.