CAPTAIN

Introduction To Web
Application Security Testing
Course Introduction
 + Understanding of Web Application
Course +
+
Web Application Architecture
Understanding of Web Application Security
Topic +
+
Web Application Testing Basics
OWASP TOP 10
Overview +
+
Reporting & Mitigation
Bug Bounty
Basic familiarity with Linux.
Familiarity with Cyber Security Prerequisites
terms and concepts.
CAPTAIN

Introduction To Web Application

Security
What Are Web Applications?
Web applications are software programs that run on web servers and are
accessible over the internet through web browsers.
They are designed to provide interactive and dynamic functionality to users,
allowing them to perform various tasks, access information, and interact with
data online.
Web applications have become an integral part of modern internet usage, and
they power a wide range of online services and activities.
Examples of web applications include:
○ Social media platforms (e.g., Facebook, Twitter)
○ Online email services (e.g., Gmail, Outlook)
○ E-commerce websites (e.g., Amazon, eBay)
○ Cloud-based productivity tools (e.g., Google Workspace, Microsoft Office )
Types of Web Application and Technogies
1. Static Web Applications
Description: Serve pre-rendered content to users, with minimal interactivity.
Examples: Portfolio websites, company landing pages.
Technologies: HTML, CSS, and limited JavaScript.
2. Dynamic Web Applications
Description: Deliver content that changes based on user interaction or server
responses.
Examples: Social media platforms, e-commerce sites.
Technologies:
1. Backend: PHP, Python (Django/Flask), Ruby on Rails, Node.js.
2. Frontend: React, Angular, Vue.js.
Web Application Architecture
A web application architecture diagram presents a layout with all the software
components (databases, applications, and middleware) and how they interact.
It defines how the data is delivered through HTTP and ensures that the client-
side and backend servers can understand.
It also ensures that valid data is present in all user requests. It creates and
manages records while providing permission-based access and authentication.
Web Application Architecture Components
1) Web Browser: The browser, client-side, or front-end component is the key
component that interacts with the user, receives the input, and manages the
presentation logic while controlling user interactions with the application. User
inputs are validated as well if required.
2) Web Server: The web server, also known as the backend or server-side
component, handles the business logic and processes the user requests by
routing the requests to the right component and managing the entire application
operations.
3) Database Server: The database server provides the required data for the
application. It handles data-related tasks. In a multi-tiered architecture, database
servers can manage business logic with the help of stored procedures.
How Do Web Applications Work?
CAPTAIN

Web Application Architecture

Protocol used in Web Application
HTTP: Enables communication between the client and the server for delivering
web content.
HTTPS: Secures HTTP communication by encrypting data using SSL/TLS.
WebSocket: Facilitates full-duplex, real-time communication between client
and server.
FTP: Transfers files between a client and server over plain text.
SFTP: Provides secure file transfer using SSH encryption.
SOAP: Exchanges structured information using XML for web services.
REST: Enables lightweight communication via HTTP/HTTPS using JSON or XML.
TLS: Provides encryption and secure communication over the network.
DNS: Translates human-readable domain names into machine-readable IP
addresses.
Protocol used in Web Application
OAuth: Manages secure authorization for third-party applications.
OpenID Connect: Extends OAuth to include user authentication.
SMTP: Handles email sending functionality in web applications.
IMAP: Allows retrieval of emails from the server while keeping them stored.
POP3: Retrieves emails from the server and downloads them locally.
 Web Application Request Method
Method Function

GET The GET method is used to retrieve data from the server. It requests the resource specified in the URL and does not modify the server's state. It is
a safe and idempotent method, meaning that making the same GET request multiple times should not have any side effects.

The POST method is used to submit data to be processed by the server. It typically includes data in the request body, and the server may perform
POST
actions based on that data. POST requests can cause changes to the server's state, and they are not idempotent.

The PUT method is used to update or create a resource on the server at the specified URL. It replaces the entire resource with the new
PUT
representation provided in the request body. If the resource does not exist, PUT can create it.

The DELETE method is used to remove the resource specified by the URL from the server. After a successful DELETE request, the resource will
DELETE
no longer be available at that URL.

PATCH The PATCH method is used to apply partial modifications to a resource. It is similar to the PUT method but only updates specific parts of the
resource rather than replacing the entire resource.

HEAD The HEAD method is similar to the GET method but only retrieves the response headers and not the response body. It is often used to check the
headers for things like resource existence or modification dates.

OPTIONS The OPTIONS method is used to retrieve information about the communication options available for the target resource. It allows clients to
determine the supported methods and headers for a particular resource.
 Common HTTP Status Code
1xx - Informational:
1. 100 Continue: Indicates the initial part of a request has been received and the
client can continue.

2xx - Success:
1. 200 OK: The request was successful, and the server returned the desired data.
2. 201 Created: The request was successful, and a new resource was created.
3. 204 No Content: The request was successful, but there is no content to return.
 Common HTTP Status Code

3xx - Redirection:
1. 301 Moved Permanently: The requested resource has been permanently
moved to a new URL.
2. 302 Found: The requested resource resides temporarily at a different URL.
3. 304 Not Modified: The requested resource has not been modified since the last
request.
 Common HTTP Status Code

4xx - Client Errors:

1. 400 Bad Request: The server could not understand the request due to invalid
syntax.
2. 401 Unauthorized: Authentication is required and has failed or not been
provided.
3. 403 Forbidden: The client does not have permission to access the resource.
4. 404 Not Found: The requested resource could not be found on the server.
5. 405 Method Not Allowed: The HTTP method used is not supported for the
requested resource.
 Common HTTP Status Code

5xx - Server Errors:

1. 500 Internal Server Error: The server encountered an unexpected condition
that prevented it from fulfilling the request.
2. 501 Not Implemented: The server does not support the functionality required
to fulfill the request.
3. 502 Bad Gateway: The server received an invalid response from an upstream
server.
4. 503 Service Unavailable: The server is currently unable to handle the request,
often due to maintenance or overload.
5. 504 Gateway Timeout: The server did not receive a timely response from an
upstream server.
Security Standards and Guidelines

OWASP Top 10: A list of the most critical web application

vulnerabilities.

ISO/IEC 27001: An information security management standard.

PCI DSS: For securing payment card information.

CAPTAIN

Understanding of
Web Application Security
Fundamental of Web Applications Security

Web application security is the practice of safeguarding websites and online

services from unauthorized access, exploitation, and attacks. Web applications are
exposed to a wide array of threats, including:
Injection attacks (e.g., SQL Injection, Command Injection).
Cross-Site Scripting (XSS).
Cross-Site Request Forgery (CSRF).
Session Hijacking and Cookie Theft.
Key Components

Authentication: Verifying user identities (e.g., using strong passwords, OTPs, or

multi-factor authentication).
Authorization: Ensuring users can access only resources and functionalities
they are allowed to.
Encryption: Securing data in transit and at rest using protocols like HTTPS and
algorithms like AES.
Input Validation: Preventing malicious input by validating and sanitizing data.
Session Management: Protecting user sessions with secure cookies, session
timeouts, and CSRF tokens.
Error Handling: Avoiding exposure of sensitive information through detailed
error messages.
 Aim of Web Application Security

The primary aim of web application security is to ensure the CIA triad:
Confidentiality: Protecting sensitive information from unauthorized access.
Example: Preventing unauthorized users from viewing data or credit card details.

Integrity: Ensuring that data is accurate and unaltered during storage or

transmission.
Example: Preventing tampering with user profiles or transaction records.

Availability: Ensuring web applications remain accessible and functional for

legitimate users.
Example: Protecting against Distributed Denial of Service (DDoS) attacks.
 Common Web Application Threats & Risks
Threat/Risk Description

Cross-Site Scripting (XSS) Attackers inject malicious scripts into web pages viewed by other users, leading to unauthorized access to user
data, session hijacking, and browser manipulation.

Attackers manipulate user input to inject malicious SQL code into the application's database, leading to
SQL Injection (SQLi)
unauthorized data access, data manipulation, or database compromise.

Attackers trick authenticated users into unknowingly performing actions on a web application, such as changing
Cross-Site Request Forgery (CSRF)
account details, by exploiting their active sessions.

Improperly configured servers, databases, or application frameworks can expose sensitive data or provide entry
Security Misconfigurations
points for attackers.

Sensitive Data Exposure Failure to adequately protect sensitive data, such as passwords or personal information, can lead to data
breaches and identity theft.

Brute-Force and Credential Stuffing Attacks Attackers use automated tools to guess usernames and passwords, attempting to gain unauthorized access to
user accounts.

File Upload Vulnerabilities Insecure file upload mechanisms can enable attackers to upload malicious files, leading to remote code
execution or unauthorized access to the server.

CAPTAIN
 Common Web Application Threats & Risks

Threat/Risk Description

Denial-of-Service (DoS) and Distributed Denial- DoS and DDoS attacks aim to overwhelm web application servers, causing service disruptions and denying
of-Service (DDoS) legitimate users access.

Server-Side Request Forgery (SSRF) Attackers use SSRF to make requests from the server to internal resources or external networks, potentially
leading to data theft or unauthorized access.

Inadequate Access Controls Weak access controls may allow unauthorized users to access restricted functionalities or sensitive data.

Using Components with Known Vulnerabilities Integrating third-party components with known security flaws can introduce weaknesses into the web application.

Broken Access Control Inadequate access controls can allow unauthorized users to access restricted functionalities or sensitive data.

CAPTAIN
CAPTAIN

Web Application Testing Basics

Types of Testing

1. Functional Testing: Functional testing, ensuring that web application

components work as intended.
Testing UI components: Verifying that buttons, links, and other interactive
elements function correctly.
Testing forms and inputs: Ensuring proper data validation, submission, and
error handling.
Testing APIs and backend services: Verifying that API endpoints return
correct responses and handle requests properly.
Types of Testing

2.Performance Testing: Performance testing, focusing on how to assess and

ensure the application's performance under various conditions.
Load testing: Simulating expected user load to test the application's
performance.
Stress testing: Applying extreme load to see how the application handles
high traffic or data processing.
CAPTAIN

LAB SETUP
Tools

Kali Linux
Burp Suite
OWASP ZAP
NESSUS
NMAP
FEROXBUSTER
SQLMAP
NIKTO
OWASP TOP 10
 Broken Access Control

1. Broken Access Control

This vulnerability occurs when a web application fails to properly enforce
restrictions on authenticated users, allowing them to perform unauthorized
actions or access sensitive resources.
Examples:
URL manipulation to access restricted pages.
Elevation of privilege by modifying access tokens.
Mitigation: Implement role-based access control (RBAC), deny access by
default, and conduct thorough access control testing.
 Cryptographic Failures

2. Cryptographic Failures
This refers to the improper implementation of cryptographic mechanisms,
leading to exposure of sensitive data such as passwords, credit card numbers,
or API keys.
Examples:
Storing passwords in plain text.
Using outdated or weak encryption algorithms like MD5.
Mitigation: Use modern encryption standards (e.g., AES-256, RSA-2048), ensure
proper key management, and enforce HTTPS.
 Injection

3. Injection
Injection vulnerabilities occur when untrusted data is sent to an interpreter as
part of a command or query, allowing attackers to execute malicious code.
Examples:
SQL Injection through unsanitized input fields.
Command Injection via shell commands.
Mitigation: Use parameterized queries, stored procedures, and input validation.
 Insecure Design

This highlights weaknesses in the application’s design that lack sufficient

security measures to mitigate potential threats.
Examples:
No rate-limiting or account lockout for login attempts.
Absence of secure architecture for critical workflows.
Mitigation: Adopt secure design principles, conduct threat modeling, and
integrate security during the software development lifecycle (SDLC).
 Security Misconfiguration

5. Security Misconfiguration
This occurs when security settings are improperly configured, exposing the
application to unnecessary risks.
Examples:
Default credentials left unchanged.
Unnecessary features like directory listing enabled.
Mitigation: Regularly review and update configurations, disable unused
features, and apply the principle of least privilege.
 Vulnerable and Outdated Components

6. Vulnerable and Outdated Components

This vulnerability arises when applications use outdated software libraries,
frameworks, or dependencies with known security flaws.
Examples:
Using an outdated version of a CMS or JavaScript library with
vulnerabilities.
Running unsupported software versions.
Mitigation: Regularly update dependencies, monitor for CVEs, and perform
software composition analysis (SCA).
 Identification and Authentication Failures

7. Identification and Authentication Failures

Weak authentication mechanisms or poor session management can allow
attackers to impersonate users or hijack their sessions.
Examples:
Weak password policies.
Lack of session expiration or secure cookies.
Mitigation: Enforce strong password policies, implement multi-factor
authentication (MFA), and use secure session management techniques.
 Software and Data Integrity Failures

8. Software and Data Integrity Failures

This occurs when applications fail to ensure the integrity of their software or
data, leading to vulnerabilities in the update process or sensitive data storage.
Examples:
Unverified software updates.
Tampered or malicious dependencies.
Mitigation: Use digital signatures for updates, restrict access to update servers,
and verify the integrity of external components.
 Security Logging and Monitoring Failures

9. Security Logging and Monitoring Failures

Inadequate logging or monitoring prevents the detection of suspicious activities
or breaches, delaying response times.
Examples:
No logs for authentication failures.
Logs stored without proper security, exposing sensitive data.
Mitigation: Implement centralized logging, monitor key events in real-time, and
perform regular log audits.
 Server-Side Request Forgery (SSRF)

SSRF occurs when an attacker tricks the server into making unintended
requests to external or internal systems, potentially exposing sensitive
information or causing harm.
Examples:
Exploiting a file upload feature to make unauthorized HTTP requests.
Querying internal services like metadata endpoints.
Mitigation: Validate and sanitize user inputs, implement allow lists for URLs, and
enforce network segmentation.
 Bug Bounty

A bug bounty is a program where organizations or companies reward ethical

hackers (security researchers) for finding and reporting security vulnerabilities
in their systems, websites, or applications. The goal is to identify and fix security
flaws before malicious hackers exploit them.
 How it works?

How It Works:
1. Companies Set Up a Bug Bounty Program
They define the scope (which systems can be tested).
They list the types of vulnerabilities they are interested in.
They specify reward amounts based on the severity of the bugs.
2. Hackers Search for Vulnerabilities
Security researchers test the system using ethical hacking techniques.
They follow responsible disclosure policies.
3. Reporting and Validation
Hackers report the found vulnerabilities.
The company's security team verifies and confirms the bug.
4. Rewards and Fixes
The hacker gets paid based on the severity of the bug (low, medium, high, critical).
The company fixes the vulnerability to improve security.