API Penetration Testing

Course Overview
Alexis Ahmed
Offensive Security/Red Team Instructor @INE
Red Team Lead @HackerSploit
 Key Concepts

+ Introduction to Web Services & APIs

+ Introduction to Web API Security
+ API Reconnaissance
+ API Authentication Testing
+ API Injection Vulnerabilities
 + Fundamentals of web
services and APIs
+ Web API Security
+ API Pentesting Methodology
MAJOR TOPICS + API Reconnaissance
+ API Authentication Testing
+ API Injection Vulnerabilities
LEARNING OUTCOMES

+ Understand the purpose and structure of APIs, including REST,

SOAP, and GraphQL.
+ Recognize common API security risks and their impact.
+ Apply a systematic methodology for API penetration testing.
+ Perform reconnaissance to discover API endpoints and resources.
+ Test API authentication mechanisms for vulnerabilities.
+ Identify and exploit API injection vulnerabilities.
 + Familiarity with the
OWASP Top 10 & OWASP
PREREQUISITES WSTG
+ Experience in using web
proxies like Burp & ZAP
LET’S GO!
Introduction To Web Services
 What Are Web Services?

● Web services are software components designed to facilitate

communication and data exchange between different applications or
systems over the internet.

● They allow disparate applications to work together, even if they are

developed on different platforms, using different programming
languages, or running on different servers.
 What Are Web Services?

● They are usually intended to facilitate:

○ Integration between applications: Application ‘A’ uses features implemented
in application ‘B’.

○ Separation within an application: Front-end scripts that use web service

functionality to dynamically update the content.
 Web Services vs Web Applications

Web Services:
● Web services are designed to facilitate communication and data
exchange between different software systems over the internet.
● They provide a standardized way for different applications to interact
with each other, often using protocols like SOAP (Simple Object Access
Protocol) or REST (Representational State Transfer).
● Web services are typically used for machine-to-machine communication
and are not meant for direct human interaction.
 Web Services vs Web Applications

Web Applications:
● Web applications are software programs that are accessed through a
web browser and are designed to perform specific tasks or provide
services directly to end-users.
● They are meant for human interaction and can range from simple
websites to complex web-based applications like email clients, social
media platforms, or online shopping sites.
Web Services vs Web Applications
Aspect Web Services Web Applications

Purpose Facilitate data exchange between Provide services or perform tasks directly for end-
applications. users.

User Interaction No user interface; meant for machine-to- Has a user-friendly interface for human
machine communication. interaction.

Data Exchange Exchanges structured data between Involves user data input, processing, and result
applications. presentation.

Communication Uses protocols like SOAP, REST, XML- Primarily uses HTTP/HTTPS for communication.
Protocol RPC, or JSON-RPC.

Security Focus Focuses on securing data during Broader security aspects, including authentication,
transmission and access control. authorization, data validation, and protection
against web vulnerabilities.

Examples Payment gateways (e.g., PayPal API), Online banking, e-commerce (Amazon), email
weather data services. (Gmail), social networking (Facebook).
Key Characteristics of Web Services

● Interoperability: Web services promote interoperability by providing a

standardized way for applications to communicate. They rely on open
standards like HTTP, XML, SOAP, REST, and JSON to ensure
compatibility.

● Platform-agnostic: Web services are not tied to a specific operating

system or programming language. They can be developed in various
technologies, making them versatile and accessible.
Key Characteristics of Web Services

● Loose Coupling: Web services allow for loosely coupled interactions

between systems. This means that changes in one system's
implementation do not necessarily disrupt the functionality of other
systems.

● Location Independence: Web services operate over the internet, making

them location-independent. They can be hosted on different servers and
accessed from anywhere with an internet connection.
Web Services Vs APIs
 Web Services Vs APIs

● Web services and APIs (Application Programming Interfaces) are related

concepts in web development, but they have distinct differences.

● Web services are a broader category of technologies used to enable

machine-to-machine communication and data exchange over the
internet. They encompass various protocols and data formats. APIs, on
the other hand, are a set of rules and tools that allow developers to
access the functionality or data of a service, application, or platform.
 Web Services Vs APIs
● Web services are a broad category of technologies and protocols
designed to facilitate communication and data exchange between
different software systems over the internet. They are meant to provide a
standardized way for various applications, often on different platforms
and using different programming languages, to interact with each other.

● APIs (Application Programming Interfaces), on the other hand, refer to

a set of rules, protocols, and tools that allow different software
applications to communicate with each other. They provide access to the
functionality or data of an application or service for developers to use in
their own applications.
 Web Services vs APIs
Aspect Web Services APIs (Application Programming Interfaces)

Purpose Facilitate data exchange between software systems. Provide access to the functionality or data of an application or
service for developers.

Communication Can use various protocols, including SOAP, REST, Can use various protocols, often associated with RESTful APIs
Protocol XML-RPC, JSON-RPC, and more. but not limited to them.

Data Format Use multiple data formats, such as XML and JSON. Can work with different data formats, including JSON, XML, or
custom formats.

Interface Do not have a user interface for direct human Do not have a user interface but are used by developers to build
interaction. applications with user interfaces.

Scope A subset of APIs, specifically focused on web-based A broader concept encompassing various types of interfaces for
data exchange. software interaction.

Standards WS-Security, WS-Policy for SOAP-based web OpenAPI (formerly Swagger) for documenting RESTful APIs,
services. GraphQL for querying APIs.
Web Service Implementations
 Web Service Implementations

● Web service implementations refer to the different ways in which web

services can be created, deployed, and used.

● There are several methods and technologies available for implementing

web services. We will be exploring them in the next set of slides.
 Web Service Implementations
● SOAP (Simple Object Access Protocol): SOAP is a protocol for
exchanging structured information in the implementation of web
services. SOAP-based web services use XML as their message format
and can be implemented using various programming languages.
● JSON-RPC and XML-RPC: JSON-RPC and XML-RPC are lightweight
protocols for remote procedure calls (RPC) using JSON or XML,
respectively. These are simpler alternatives to SOAP for implementing
web services.
● REST (Representational State Transfer): REST is an architectural style for
designing networked applications, and it uses HTTP as its
communication protocol.
 XML-RPC
● XML-RPC (Extensible Markup Language - Remote Procedure Call)
created in 1998, is a protocol and a set of conventions for encoding and
decoding data in XML format and using it for remote procedure calls
(RPC).
● It is a simple and lightweight protocol for enabling communication
between software applications running on different systems, often over
a network like the internet.
● XML-RPC has been used as a precursor to more modern web service
protocols like SOAP and REST.
● It works by sending HTTP requests that call a single method
implemented on the remote system.
XML-RPC - Request Example
Request headers such as user agent,
hosts, content type etc.

Payload format in XML.

Must contain <methodCall> with the

<methodName> sub-item.

XML-RPC encodes data in XML format,

which is both human-readable and
machine-readable. It uses XML tags to
represent data types and method calls.
 XML-RPC - Requests & Responses
<?xml version="1.0"?>
<methodCall>
<methodName>sampleMethod</methodName>
<params>
<param> REQUEST
<value><int>42</int></value>
</param>
</params>
</methodCall>

<?xml version="1.0"?>
<methodResponse>
<params> RESPONSE
<param>
<value><string>Hello, World!</string></value>
</param>
</params>
</methodResponse>
 JSON-RPC
● JSON-RPC (Remote Procedure Call) is a remote procedure call (RPC)
protocol encoded in JSON (JavaScript Object Notation).
● Like XML-RPC, JSON-RPC enables communication between software
components or systems running on different machines or platforms.
● JSON-RPC is known for its simplicity and ease of use and has become
popular in web development and microservices architectures.
● JSON-RPC is very similar to XML-RPC, however, it is usually used
because it provides much more human-readable messages and takes
less data to for communication.
● JSON-RPC allows a client to invoke methods or functions on a remote
server by sending a JSON object that specifies the method to call and its
parameters.
 JSON-RPC

● The message sent to invoke a method is a request with a single object

serialized using JSON. It has three properties:
○ method: name of the method to invoke
○ params: an array of objects to pass as arguments
○ id: request ID used to match the responses/requests
JSON-RPC - Request Example

Request Headers
like User-Agent,
Host etc

This is a single object serialized using

JSON. Note the three properties:
method, params and id.
 SOAP
● SOAP (Simple Object Access Protocol) is a protocol for exchanging
structured information in the implementation of web services.
● It is a protocol that defines a set of rules and conventions for structuring
messages, defining remote procedure calls (RPC), and handling
communication between software components over a network, typically
the internet.
● SOAP is seen as the natural successor to XML-RPC and is known for its
strong typing and extensive feature set, which includes security,
reliability, and transaction support.
● SOAP Web Services may also provide a Web Services Definition
language (WSDL) declaration that specifies how they may be used or
interacted with.
SOAP - Request Example

Request headers such

as user agent, hosts,
content type etc.

Body of the
request (XML)
 SOAP - Requests & Responses
<soapenv:Envelope
xmlns:soapenv="[Link]
xmlns:web="[Link]
<soapenv:Header/>
<soapenv:Body> REQUEST
<web:sampleMethod>
<web:inputParameter>42</web:inputParameter>
</web:sampleMethod>
</soapenv:Body>
</soapenv:Envelope>

<soapenv:Envelope
xmlns:soapenv="[Link]
xmlns:web="[Link] RESPONSE
<soapenv:Header/>
<soapenv:Body>
<web:sampleMethodResponse>
<web:result>Hello, World!</web:result>
</web:sampleMethodResponse>
</soapenv:Body>
</soapenv:Envelope>
 REST (RESTful APIs)
● REST, which stands for Representational State Transfer, is an
architectural style for designing networked applications. It is not a
protocol or technology itself but rather a set of principles and constraints
that guide the design of web services and APIs (Application
Programming Interfaces).
● REST is widely used for building scalable, stateless, and easy-to-
maintain web services/APIs that can be accessed over the internet.
● REST web services generally use JSON or XML, but any other message
transport format like plain-text can be used.
 REST (RESTful APIs)
HTTP Method Action

GET Retrieve a resource on the server, list a collection of records

• [Link] (e.g. List all books available)
•[Link] (e.g. View a specific book)
PUT Change the state of a resource, replace or create it if it does not exist
•[Link] (e.g. Replace a book)
POST Create a new resource or record
•[Link] (e.g. Create a specific book)
DELETE Delete a resource or record
•[Link] (e.g. Delete a book)
WSDL Language Fundamentals
 Introduction
A web service is characterized by:
 WSDL
● WSDL, which stands for Web Services Description Language, is an
XML-based language used to describe the functionality and interface of
a web service.

● WSDL documents serve as contracts between service providers and

consumers, specifying how a web service can be used.

● WSDL is commonly used in conjunction with SOAP (Simple Object

Access Protocol) to define and document SOAP-based web services.
 WSDL Versions

● At the time of writing, WSDL can be distinguished in two main versions:

1.1 and 2.0.

● Although 2.0 is the current version, many web services still use WSDL
1.1 therefore, in the next slides we will see both WSDL specifications.
 WSDL

● First of all, it is important to know that WSDL documents have abstract

and concrete definitions:

○ Abstract: describes what the service does, such as the operation provided,
the input, the output and the fault messages used by each operation

○ Concrete: adds information about how the web service communicates and
where the functionality is offered
 WSDL
The following image shows the main differences between WSDL 1.1 and
WSDL 2.0 definitions. We will inspect the most important elements in future
slides.
 WSDL Documents
● A WSDL document is typically created to describe a SOAP-based web
service. It defines the service's operations, their input and output
message structures, and how they are bound to the SOAP protocol.

● The WSDL document effectively documents the API provided by the

service.

● The WSDL document serves as a contract between the service provider

and consumers. It specifies how clients should construct SOAP requests
to interact with the service. This contract defines the operations, their
input parameters, and expected responses.
Interaction Between Client & Web Service
 WSDL Components
● Types: The <types> section defines the data types used in the web
service. It typically includes XML Schema Definitions (XSD) that specify
the structure and constraints of input and output data.
● Message: The <message> element defines the data structures used in
the messages exchanged between the client and the service. Messages
can have multiple parts, each with a name and a type definition
referencing the types defined in the <types> section.
● Port Type: The <portType> element describes the operations that the
web service supports. Each operation corresponds to a method or
function that a client can invoke. It specifies the input and output
messages for each operation.
 WSDL Components
● Binding: The <binding> element specifies how the service operations are
bound to a particular protocol, such as SOAP over HTTP. It defines
details like the protocol, message encoding, and endpoint addresses.

● Service: The <service> element provides information about the service

itself. It includes the service's name and its endpoint address, which is
the URL where clients can access the service.
 Binding
● The <binding> element specifies how the service operations are bound
to a particular protocol, such as SOAP over HTTP. It defines details like
the protocol, message encoding, and endpoint addresses.
 PortType
● The <portType> element describes the operations that the web service
supports. Each operation corresponds to a method or function that a
client can invoke. It specifies the input and output messages for each
operation.
 Operation
● The operation object defined within a port type, represents a specific
action that a service can perform. It specifies the name of the operation,
the input message structure, the output message structure, and,
optionally, fault messages that can occur during the operation.
 Interface
● Instead of portType, WSDL v. 2.0 uses interface elements which define a
set of operations representing an interaction between the client and the
service. Each operation specifies the types of messages that the service
can send or receive.

● Unlike the old portType, interface elements do not point to messages

anymore (it does not exist in v. 2.0). Instead, they point to the schema
elements contained within the types element.
WSDL Disclosure & Method Enumeration
 WSDL Disclosure

● When dealing with web service security, accessing the WSDL file is the
first step; this gives us the full list of operations and types allowed by
the server as well as the correct syntax to use, inputs, outputs and all the
useful information we may need to run successful attacks.

● Before we can enumerate the WSDL file for the SOAP web service, we
need to identify the SOAP web service and endpoints.
 WSDL Disclosure
● Once the SOAP service has been identified, another way to discover
WSDL files is by appending ?wsdl,.wsdl or ?disco to the end of the
service URL:
 WSDL Disclosure

● Once we find WSDL files, we can start inspecting them and gather
valuable information about the web service.

● As you already know, this allows us to gather information such as

operations, data, syntax and much more.
Demo: WSDL Disclosure &
Method Enumeration
Invoking Hidden Methods
Demo: Invoking Hidden Methods
Testing For SQL Injection
Demo: Testing For SQL Injection
Testing For Command
Injection
Demo: Testing For Command
Injection
Misconfigured Permissions
Demo: Misconfigured Permissions
Improper Input Validation
Demo: Improper Input Validation
Parameter Tampering
Demo: Parameter Tampering
Security Misconfiguration
Demo: Security Misconfiguration
API Penetration Testing

Course Summary
 Key Concepts - Recap

+ Introduction to Web Services & APIs

+ Introduction to Web API Security
+ API Reconnaissance
+ API Authentication Testing
+ API Injection Vulnerabilities
Learning Outcomes Recap

+ Understand the purpose and structure of APIs, including REST,

SOAP, and GraphQL.
+ Recognize common API security risks and their impact.
+ Apply a systematic methodology for API penetration testing.
+ Perform reconnaissance to discover API endpoints and resources.
+ Test API authentication mechanisms for vulnerabilities.
+ Identify and exploit API injection vulnerabilities.
 Real-World Applications
+ Securing APIs in Real-World Environments: Use your understanding of
API fundamentals to identify and address vulnerabilities in modern web
services.
+ Enhancing Organizational Security: Apply API security principles to
strengthen the overall security posture of web applications.
+ Executing Professional Penetration Tests: Leverage a structured
methodology to conduct thorough and effective API penetration tests.
+ Identifying API Weak Points: Perform detailed reconnaissance to uncover
exposed endpoints and assess their risk.
+ Hardening Authentication Systems: Evaluate and improve API
authentication mechanisms to prevent unauthorized access.
 Next Steps
+ Explore Advanced API Security Topics: Dive into areas like OAuth 2.0,
OpenID Connect, API rate limiting, and secure API design principles.

+ Learn API Testing Automation: Master tools like Postman, Burp Suite,
and OWASP ZAP for automated API security testing.

+ Study Cloud API Security: Understand API security in cloud

environments, focusing on AWS, Azure, and Google Cloud APIs.
THANKS FOR WATCHING!
EXPERTS AT MAKING YOU AN EXPERT