Injektio on haavoittuvuus, jossa yritetään parameterisoida jotain protokollaa, mutta parametriksi tarkoitettu data pääseekin murtautumaan ulos parametrin paikastaan ja muodostuu osaksi protokollan rakennetta.

URL-injektio on tästä yksinkertainen esimerkki. Kun sovellus rakentaa URL-osoitteita, esimerkiksi tehdäkseen taustajärjestelmässä kutsun toiseen (sisäiseen) taustajärjestelmään, ja lisää rakennettuun URL-osoitteeseen jonkun polun tai parametrin esimerkiksi käyttäjän syötteestä, on riski URL-injektioon jos syötettä ei ole enkoodattu oikein.

Seuraava kuva kuvastaa tilannetta, jossa URL-injektioita voi sijaita.

Yllä olevassa kuvassa verkkosivu suorittaa taustapalveluun HTTP-pyynnön käyttämällä käyttäjän antamaa tunnusta osana URL-osoitteen polkua.

Tämä vaikuttaa täysin turvalliselta sekä viattomalta, mutta mitä tapahtuu, jos käyttäjä antaakin tunnuksen sijaan arvon, joka uudelleenmäärittää verkkosivun tekemän kyselyn lopullisen sijainnin. Jos verkkosivu ei rakenna URL-osoitteita turvallisesti, niin tämä voi mahdollistaa esimerkiksi 

merkkijonon käyttämistä syötteessä, jolla voidaan joskus matkustaa URL-polussa taaksepäin.

Yllä olevassa kyselyssä, käyttäjä antoi syötteenä

, joka muokkasi verkkosivun tekemän kyselyn lopullista sijaintia, jolloin sovellus päätyikin tekemään sisäisen HTTP-pyynnön eri polkuun kuin kehittäjä oli tarkoittanut.

Käynnistä nyt alla oleva harjoitus ja lue eteenpäin.

Etsi ja tunnista URL-injektio haavoittuvuus ja hyväksikäytä tätä.

Tehtävässä käytetyn sovelluksen lähdekoodit:

URL-injektio harjoitus

Aloitamme suorittamalla sovelluksessa olevan rekisteröitymisen. Tarkistamme BurpSuite-ohjelmasta, tästä aiheutuneen HTTP-pyynnön.

Huomaamme, että rekisteröityminen aiheuttaa HTTP-pyynnön rajapintaan 

. Varmistetaan rajapinnan toiminta lähdekoodista.

Rajapinnan käyttämästä koodista näkee, että sovellus ottaa vastaan annetun sähköpostiosoitteen ja suorittaa uuden kyselyn rajapintaan 

+ sposti. Lähdekoodista näemme myös, että sovellus ei suorita minkäänlaista formatointia annetulle sähköpostiosoitteelle, mikä tarkoittaa, että sovellus on haavoittuvainen URL-injektio hyökkäyksille.

Jos tutkimme kyseisen rajapinnan koodia, huomaamme, ettei rajapintaan voi suorittaa itse kyselyitä, sillä rajapinta tarkistaa, että kyselyt saapuvat osoitteesta 127.0.0.1.

Tutkimalla lähdekoodia lisää, voimme todeta, että sovelluksessa on myös toinen sisäinen rajapinta, jossa tehdään IP-osoitteen tarkistus.

Kyseinen rajapinta näyttää yksinkertaisesti palauttavan kaikki sovelluksen käyttäjät tietokannasta. Käytetään löydettyä URL-injektio haavoittuvuutta ja uudelleenohjataan 

rajapinnan tekemä kysely, yllä olevaan 

Voila! - Onnistuimme tekemään HTTP-pyynnön, jossa uudelleenohjasimme palvelimen suorittaman HTTP-pyynnön toiseen rajapintaan ja tämä palautti meille Flag:in.

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ä.

Kuinka rakennan URL-osoitteet turvallisesti?

## 

---

## Injektiot yleisesti

Injektio on haavoittuvuus, jossa yritetään parameterisoida jotain protokollaa, mutta parametriksi tarkoitettu data pääseekin murtautumaan ulos parametrin paikastaan ja muodostuu osaksi protokollan rakennetta.

---

## URL-injektio

URL-injektio on tästä yksinkertainen esimerkki. Kun sovellus rakentaa URL-osoitteita, esimerkiksi tehdäkseen taustajärjestelmässä kutsun toiseen (sisäiseen) taustajärjestelmään, ja lisää rakennettuun URL-osoitteeseen jonkun polun tai parametrin esimerkiksi käyttäjän syötteestä, on riski URL-injektioon jos syötettä ei ole enkoodattu oikein.

---

## Esimerkki

Seuraava kuva kuvastaa tilannetta, jossa URL-injektioita voi sijaita.

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

Yllä olevassa kuvassa verkkosivu suorittaa taustapalveluun HTTP-pyynnön käyttämällä käyttäjän antamaa tunnusta osana URL-osoitteen polkua.

```python
url = "/varattu/" + kayttajan_antama_syote
```

Tämä vaikuttaa täysin turvalliselta sekä viattomalta, mutta mitä tapahtuu, jos käyttäjä antaakin tunnuksen sijaan arvon, joka uudelleenmäärittää verkkosivun tekemän kyselyn lopullisen sijainnin. Jos verkkosivu ei rakenna URL-osoitteita turvallisesti, niin tämä voi mahdollistaa esimerkiksi **../ **merkkijonon käyttämistä syötteessä, jolla voidaan joskus matkustaa URL-polussa taaksepäin.

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

Yllä olevassa kyselyssä, käyttäjä antoi syötteenä** ../kayttajat**, joka muokkasi verkkosivun tekemän kyselyn lopullista sijaintia, jolloin sovellus päätyikin tekemään sisäisen HTTP-pyynnön eri polkuun kuin kehittäjä oli tarkoittanut.

---

## Harjoitus

Käynnistä nyt alla oleva harjoitus ja lue eteenpäin.

@exercise ef71b6981831

Aloitamme suorittamalla sovelluksessa olevan rekisteröitymisen. Tarkistamme BurpSuite-ohjelmasta, tästä aiheutuneen HTTP-pyynnön.

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

Huomaamme, että rekisteröityminen aiheuttaa HTTP-pyynnön rajapintaan **/varmista**. Varmistetaan rajapinnan toiminta lähdekoodista.

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

Rajapinnan käyttämästä koodista näkee, että sovellus ottaa vastaan annetun sähköpostiosoitteen ja suorittaa uuden kyselyn rajapintaan **/api/user/ **+ sposti. Lähdekoodista näemme myös, että sovellus ei suorita minkäänlaista formatointia annetulle sähköpostiosoitteelle, mikä tarkoittaa, että sovellus on haavoittuvainen URL-injektio hyökkäyksille.

Jos tutkimme kyseisen rajapinnan koodia, huomaamme, ettei rajapintaan voi suorittaa itse kyselyitä, sillä rajapinta tarkistaa, että kyselyt saapuvat osoitteesta 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'):
    ...
```

Tutkimalla lähdekoodia lisää, voimme todeta, että sovelluksessa on myös toinen sisäinen rajapinta, jossa tehdään IP-osoitteen tarkistus.

```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 })
```

Kyseinen rajapinta näyttää yksinkertaisesti palauttavan kaikki sovelluksen käyttäjät tietokannasta. Käytetään löydettyä URL-injektio haavoittuvuutta ja uudelleenohjataan **/varmista **rajapinnan tekemä kysely, yllä olevaan **/api/users **rajapintaan.

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

Voila! - Onnistuimme tekemään HTTP-pyynnön, jossa uudelleenohjasimme palvelimen suorittaman HTTP-pyynnön toiseen rajapintaan ja tämä palautti meille Flag:in.

@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);
```

Epäturvallisesti rakennetut URL-osoitteet tai URL-injektio

Injektioita on joskus yllättävissäkin paikoissa ja URL-osoitteiden rakentaminen on yleinen paikka, jossa kehittäjät unohtavat huomioida vaaran.

Epäturvallisesti rakennetut URL-osoitteet tai URL-injektio

Hakkeroinnin oppiminen alkaa tästä