Injection is a vulnerability where an attempt is made to parameterize a protocol, but the data intended as a parameter instead breaks out of its parameter position and becomes part of the protocol structure.

URL injection is a simple example of this. When an application constructs URL addresses, for example, to make a call to another (internal) background system, and adds a path or parameter from user input to the constructed URL address, there is a risk of URL injection if the input is not properly encoded.

The following image represents a situation where URL injections may be located.

In the above picture, the webpage is making an HTTP request to a background service using the user-provided credential as part of the URL path.

This seems completely safe and innocent, but what happens if the user provides a value instead of a username that redefines the final location of the query made by the website? If the website does not construct URLs securely, this can allow the use of the 

 string in the input, which can sometimes be used to travel backwards in the URL path.

, which modified the final location of the query made by the website, causing the application to make an internal HTTP request to a different path than intended by the developer.

Start the exercise below and continue reading.

Find and identify URL injection vulnerability and exploit it.

URL injection exercise

We start by performing the registration that is available in the application. We check the HTTP request resulting from this in the Burp Suite program.

We notice that registration causes an HTTP request to the interface 

. Let's verify the interface's functionality from the source code.

The code used by the interface shows that the application accepts a given email address and performs a new query to the interface 

 + email. We can also see from the source code that the application does not perform any kind of formatting on the given email address, which means that the application is vulnerable to URL injection attacks.

If we examine the code of the interface in question, we notice that it is not possible to execute queries on the interface itself, as the interface verifies that queries arrive from the address 127.0.0.1.

By examining the source code further, we can see that there is another internal API in the application that performs IP address verification.

The interface in question simply returns all the application users from the database. A found URL injection vulnerability is utilized to redirect the query made by the interface to the 

Voila! - We succeeded in making an HTTP request, redirecting the server's HTTP request to another API, and this returned us the Flag:.

The most important thing is to remember that we do not want the user to be able to redefine the structure of the HTTP request made in the application. For this purpose, URL encoding can be used, for which there are various libraries available, depending on what solutions you use. For example, in Node.js applications, you can use the 

 function, to which you input the data received from the user before setting it to the final URL address.

This must also be remembered when using user-provided information in parameters so that the attacker cannot manipulate the parameters used in queries.

Tärkeintä on muistaa, että emme halua käyttäjän kykenevän uudelleenmäärittämään sovelluksessa tehtävän HTTP-pyynnön rakennetta. Tähän tarkoitukseen voidaan käyttää URL-enkoodausta, johon löytyy erilaisia kirjastoja, riippuen hieman, mitä ratkaisuja käytät. Esimerkiksi, Node.js sovelluksissa voit käyttää 

funktiota, johon syötät käyttäjältä saadun tiedon, ennen kuin asetat tämän lopulliseen URL-osoitteeseen.

Tämä täytyy myös muistaa, kun käytät käyttäjältä saatua tietoa parametreissä, ettei hyökkääjä kykene manipuloimaan kyselyissä käytettyjä parametrejä.

How do I build URLs securely?

Kuinka rakennan URL-osoitteet turvallisesti?

## 

---

## Common Injections

Injection is a vulnerability where an attempt is made to parameterize a protocol, but the data intended as a parameter instead breaks out of its parameter position and becomes part of the protocol structure.

---

## URL Injection

URL injection is a simple example of this. When an application constructs URL addresses, for example, to make a call to another (internal) background system, and adds a path or parameter from user input to the constructed URL address, there is a risk of URL injection if the input is not properly encoded.

---

## Example

The following image represents a situation where URL injections may be located.

![](sanity:image-c1114629b39e1f99510485a6e50c8a46b7618c7b-1125x401-png)

In the above picture, the webpage is making an HTTP request to a background service using the user-provided credential as part of the URL path.

```python
url = "/busy/" + user_given_syote
```

This seems completely safe and innocent, but what happens if the user provides a value instead of a username that redefines the final location of the query made by the website? If the website does not construct URLs securely, this can allow the use of the **../** string in the input, which can sometimes be used to travel backwards in the URL path.

![](sanity:image-13409a966eb31f5456a4f669134da9022fe3ca26-1125x401-png)

In the above query, the user input** ../kayttajat**, which modified the final location of the query made by the website, causing the application to make an internal HTTP request to a different path than intended by the developer.

---

## Exercise

Start the exercise below and continue reading.

@exercise ef71b6981831

We start by performing the registration that is available in the application. We check the HTTP request resulting from this in the Burp Suite program.

![](sanity:image-61ba1eeae364c5668eb5702c64cad2746142588f-829x356-png)

We notice that registration causes an HTTP request to the interface **/verify**. Let's verify the interface's functionality from the source code.

```python
@app.route("/verify", methods=['POST'])
def verify():
  mail = request.form.get("mail")
  response = requests.get("http://127.0.0.1:5000/api/user/"+sposti)
  return jsonify(response.json())
```

The code used by the interface shows that the application accepts a given email address and performs a new query to the interface **/api/user/** + email. We can also see from the source code that the application does not perform any kind of formatting on the given email address, which means that the application is vulnerable to URL injection attacks.

If we examine the code of the interface in question, we notice that it is not possible to execute queries on the interface itself, as the interface verifies that queries arrive from the address 127.0.0.1.

```python
@app.route("/api/user/<user_mail>")
def user_api(user_mail):
    ip_address = flask.request.remote_addr
    if ip_address not in ('127.0.0.1', '::1', 'localhost'):
    ...
```

By examining the source code further, we can see that there is another internal API in the application that performs IP address verification.

```python
@app.route("/api/users", methods=['GET'])
def users_api():
    ip_address = flask.request.remote_addr
    if ip_address not in ('127.0.0.1', '::1', 'localhost'):
      abort(404)
    
    users = database.get_users()
    return jsonify({ 'Users': users })
```

The interface in question simply returns all the application users from the database. A found URL injection vulnerability is utilized to redirect the query made by the interface to the **/verify** endpoint mentioned above, to the **/api/users** interface.

![](sanity:image-fa3eb1a7abdc29b15bac91904dd22ae8677f044e-976x370-png)

Voila! - We succeeded in making an HTTP request, redirecting the server's HTTP request to another API, and this returned us the Flag:.

@embed c397d59be150


Tärkeintä on muistaa, että emme halua käyttäjän kykenevän uudelleenmäärittämään sovelluksessa tehtävän HTTP-pyynnön rakennetta. Tähän tarkoitukseen voidaan käyttää URL-enkoodausta, johon löytyy erilaisia kirjastoja, riippuen hieman, mitä ratkaisuja käytät. Esimerkiksi, Node.js sovelluksissa voit käyttää **encodeURIComponent **funktiota, johon syötät käyttäjältä saadun tiedon, ennen kuin asetat tämän lopulliseen URL-osoitteeseen.



```javascript
//Haavoittuv:
var url = "http://taustapalvelu.com/api/esim/" + tunnus; 

//Ei haavoittuva
var url = "http://taustapalvelu.com/api/esim/" + encodeURIComponent(tunnus);
```



Tämä täytyy myös muistaa, kun käytät käyttäjältä saatua tietoa parametreissä, ettei hyökkääjä kykene manipuloimaan kyselyissä käytettyjä parametrejä.



```javascript
//Haavoittuva
var url = "http://taustapalvelu.com/api/tunnus?nimi=" + nimi;
// nimi parametri sisältää "bob&poista=true"

//Ei haavoittuva
var url = "http://taustapalvelu.com/api/tunnus?nimi="+ encodeURIComponent(nimi);
```

Insecurely constructed URLs or URL injection

Injections can sometimes be found in surprising places, and building URLs is a common place where developers forget to consider the danger.

Injects can sometimes be found in even unexpected places and constructing URL addresses is a common place where developers forget to consider the danger.

Insecurely constructed URLs or URL injection

Learn to hack — start here