Web Services, APIs, Webhooks, Web Shells and Web App Security

What it is

A web service lets programs talk to each other over the web. An application programming interface (API) is the set of calls a program exposes. A webhook is the reverse: a server sends an HTTP request to a registered address when an event occurs.

A web shell is a malicious script placed on a web server that gives an attacker remote control. The page ends with the controls that secure a web application as a whole.

How it works

Attack web services

Typical attacks include:

• Reconnaissance: the WSDL file lists every operation and parameter, so an exposed WSDL is a map for the attacker.
• XML injection and XXE: malformed or malicious XML sent to a parser.
• SOAP action spoofing and parameter tampering: altering operation names or values.
• Injection: SQL, command or XPath injection through service parameters.
• Replay and man in the middle: capturing and resending valid messages.
• Denial of service: very large or deeply nested XML.
• Authentication flaws: weak keys, missing tokens or accepting unsigned messages.

Defenses: validate messages against a schema, disable external entities, require authentication and signed messages, use TLS, restrict who can read the WSDL, and rate limit.

Web API threats

APIs expose data directly, so authorization flaws are the most serious. The OWASP API Security Top 10 starts with broken object level authorization, which is the API form of IDOR. Other common issues:

GraphQL and REST APIs are tested with an intercepting proxy or tools such as Postman and Burp Suite. Defenses are strong token authentication (OAuth 2.0 and JWT with signature validation), authorization on every object, returning only needed fields, schema validation, rate limits and an API inventory.

Webhooks

A webhook posts event data to a URL the receiver provides. Risks and fixes:

• Spoofed callbacks: an attacker posts fake events. Verify a shared secret signature (an HMAC of the body) on every request.
• Replay: include and check a timestamp or unique ID.
• Server side request forgery: if users supply the webhook URL, the server may be tricked into calling internal addresses. Validate destinations and block internal ranges.
• Data exposure: sending sensitive data over plain HTTP. Use HTTPS only.

Web shells

A web shell is a script (in PHP, ASP.NET, JSP or similar) uploaded to a server, which gives the attacker a browser based interface to run commands, browse files and move deeper. It is usually installed through a file upload flaw, an injection or a stolen credential. China Chopper is a well known small example.

Detection: file integrity monitoring and comparing the web root with a known good copy, scanning for suspicious functions that run commands, unusual new files in upload folders, unexpected outbound connections, and web logs showing requests to one odd file. Prevention: validate and restrict uploads, store uploads outside the web root, disable script execution in upload folders, patch, and run the server with low privilege.

Web application security

Tools worth knowing: OWASP ZAP and Burp Suite for dynamic testing, ModSecurity as an open source WAF engine, and dependency checkers for vulnerable libraries.

A worked example

An image upload accepts any file and stores it in a public folder. Later requests to a single new .php file arrive and the server starts connecting to an unknown address. The upload flaw let an attacker install a web shell. The remedy is to remove the file, check what ran, restrict uploads by type and content, and stop script execution in that folder.

How the exam asks about this

• "Which file describes a SOAP service's operations and may help an attacker map it?" -> The WSDL file.
• "An API returns another user's record when the ID is changed. Which API risk?" -> Broken object level authorization.
• "A script uploaded to a server that gives remote command access is called what?" -> A web shell.