Business Security Testing: Concepts, Techniques, and Practical Tools

1. Background

1.1 What is Business Security Testing Traditional security vulnerabilities focus on generic technical flaws such as DoS attacks, WebShell privilege escalation, XSS, ActiveX exploits, sniffing, and buffer overflows. Business security testing builds on these by considering the specific business scenarios, ignoring underlying OS, API, hardware, or network dependencies and focusing on risks introduced by the actual business logic.

(Figure 1.1 Business Security Testing)

1.2 Overall Overview

Typical product lines follow a flow from client devices to servers and then to databases. At the server entry point a routing decision is made, and another routing decision occurs before reaching the database, as illustrated below.

(Figure 1.2 Overall Business Flow)

Three client types are typical: a native mobile app, a mobile browser, and a traditional desktop browser. Requests are authorized and routed before reaching the highlighted nodes where business logic executes, after which data is read or written to the database.

Our business security testing starts from the client side, sending specially crafted requests to see whether they affect backend data or other clients. While the requests are technically legitimate, they may expose business‑level security weaknesses.

2. Security Testing Techniques

Security testing is divided into five technical stages: analyzing business resource interfaces, extracting business interfaces, tampering with those interfaces, forging realistic user sessions, and performing replay attacks.

(Figure 2.1 Security Testing Techniques)

2.1 Network Request Interception

a. TamperIE Interception Any request sent from a browser or app can be intercepted before it leaves the client using plugins or tools. For Internet Explorer, the TamperIE plugin allows modification of request parameters, as shown below.

(Figure 2.2 TamperIE intercepting a request)

Requests can be GET or POST. GET parameters are edited directly in the URL, while POST data must be constructed and appended to the request body.

b. Chrome Network Interception Chrome’s built‑in DevTools provides a powerful, though English‑only, interface for capturing HTTP traffic. Open it via Menu → More tools → Developer tools, then start recording by clicking the red record button.

(Figure 2.3 Chrome network capture)

Each request can be inspected for headers, method, payload, cookies, etc.

c. tcpdump Capture On mobile devices, tcpdump is a common free network analysis tool. It runs with root privileges, puts the interface into promiscuous mode, and can capture traffic for both defensive and offensive analysis.

(Figure 2.4 tcpdump installation)

2.2 Client‑Side User Information Tampering

a. Cookie Tampering Cookies are key/value pairs stored by browsers and sent with each request. They often contain session data and can be altered using extensions such as EditThisCookie, enabling arbitrary modification of values like flags or domain URLs, effectively turning a trusted user into an untrusted one.

(Figure 2.5 Edit This Cookie tool)

2.3 Forging Backend Authentication

Clients normally store authentication data locally and send it with each request. By understanding the server’s verification algorithm and secret keys, an attacker can construct a complete authentication flow, as illustrated below.

(Figure 2.6 Authentication process)

2.4 Replay Attack on Service Interfaces

With a forged signature, an attacker can repeatedly invoke any API endpoint (httpGet, httpPost, httpsGet, httpsPost). High‑frequency requests reveal whether the server imposes rate limits and how it handles them. The following diagram shows the four request types used in the replay tests.

(Figure 2.7 Request interfaces)

a. Replay GET Request GET parameters are appended to the URL and may be URL‑encoded or Base64‑encoded for non‑ASCII characters. GET requests are limited by URL length and are cached by browsers, exposing credentials in the address bar.

b. Replay POST Request POST sends data in the request body, avoiding URL length limits and offering better confidentiality. POST data is accessed server‑side via Request.Form and can modify server resources.