SQL:n ORDER BY -lauseke, kuten olet jo UNION-tekniikkaan tutustuessa oppinut, lajittelee tietokannasta palautuneet rivit joko sarakkeen nimen tai järjestysnumeron (ordinal) perusteella. ORDER BY ottaa lisäksi suuntaparametrin, jonka arvo voi olla ASC (ascending = nouseva) tai DESC (descending = laskeva).

Esimerkiksi tällainen kysely hakisi kaikki rivit tuotteet-taulusta ja lajittelisi ne hinnan mukaan nousevassa (halvin ensin) järjestyksessä:

Mutta entäs jos SQL injektio onkin ORDER BY -lausekkeessa? Tällaista haavoittuvuutta esiintyy melko usein, kun sovellukset esimerkiksi antavat käyttäjän järjestää taulukon tietyn sarakkeen mukaan.

Otetaan käytännön esimerkki tutusta verkkopankista. Kontaktilistauksen voi lajitella etunimen, sukunimen, sähköpostin tai tilinumeron perusteella.

Sovellus ottaa lajitteluparametrin query-parametrina (URL-osoitteesta) ja käyttää parametria rakentamaan SQL-kyselyn.

Mitä tapahtuu jos sovellus on haavoittuva SQL -injektiohyökkäyksille ja hyökkääjä antaakin sort-parametrin arvoksi "

email UNION SELECT username, password FROM users-- 

SQL-syntaksi ei salli UNION-lausekkeita enää ORDER BY jälkeen. Toisin sanoen, injektiopiste on liian myöhään SQL-kyselyn rakenteessa, jotta voisimme enää käyttää UNION-tekniikkaa. Voit toki kokeilla! Mutta näin siinä käy: 

Joudumme siis turvautumaan hieman luovempaan, niin kutsuttuun virhepohjaiseen tekniikkaan.

Virhepohjaisen tekniikan perusidea on seuraavanlainen: 

Rakennetaan tahallaan SQL-kysely, joka aiheuttaa virheen.

Huolehditaan, että virhe sisältää tiedot, joita halutaan tietokannasta viedä.

Tuodaan virhe meidän (hyökkääjän) näkyville.

Onnistuakseen virhepohjainen tekniikka vaatii siis että sovellus palauttaa tekniset virheilmoitukset sellaisenaan palvelimelta selaimelle meidän nähtäväksi. Tämä on yksi syy, miksi tietoturvatarkastajat muistavat aina huomauttaa sovelluksen virheidenhallinnan tärkeydestä. Virheiden vuotaminen tekee haavoittuvuuksien löytämisestä ja hyväksikäyttämisestä merkittävästi helpompaa, ja tässä tapauksessa ylipäätään mahdollista.

SQL-syntaksi sisältää monenlaisia funktioita. Olemme tähän mennessä tutustuneet vain concat-funktioon joka yhdistelee tekstiä. Nyt tutustumme toiseen funktioon, nimeltä ExtractValue, joka liittyy XML-käsittelyyn. Funktion "oikea" käyttötarkoitus ei ole tärkeä, mutta tässä on kuitenkin esimerkki siitä miten sitä olisi tarkoitus käyttää: 


Funktio siis ottaa ensimmäisenä parametrina XML:ää, ja toisena parametrina XPATH-valitsimen, jolla poimitaan tietoja XML:stä. Ei haittaa, jos et tiedä mitä XML ja XPATH ovat, opit niistä toisella kurssilla. Oleellista on, että 

-funktio aiheuttaa epäonnistuessaan virheen, joka tulostaa XPATH-valitsimen

Miten siis saisimme XPATH-valitsimen arvon sisältämään sekä 

 -merkin (joka aiheuttaa tarvittavan virheen) että mitä tahansa mitä tietokannasta halutaan nähdä? Tietysti 

 ja alikyselyt) pitäisi olla sinulle jo tuttuja.

syntaksi tukee useampaa parametria, esimerkiksi näin: Kysely listaisi tuotteet hinnan mukaan järjesteltynä, ja niistä, joiden hinta on sama, näytettäisiin ensin ne, jotka ovat varastossa.

Voimme laittaa alikyselyn toiseksi järjestysparametriksi, näin: 

 -lajitteluparametri (eli pilkku edellisen perään), ja laita sen arvoksi uusi alikysely.

Muodosta alikysely niin, että se käyttää ExtractValue-funktiota, ensimmäisenä parametrina vaikka numeroa 

 (tällä ei ole juurikaan väliä), ja toisena parametrina 

-funktiokutsua, joka puolestaan ottaa ensimmäisenä parametrina 

 -merkin ja toisena parametrina alikyselyn, joka hakee tiedot joita haluat nähdä.

CONCAT(email, ":", password) FROM user WHERE admin=True LIMIT 1 

eli sähköposti ja salasana ensimmäiseltä admin-käyttäjältä, varmistaen 

-lausekkeella ettei alikysely palauta ylimääräisiä rivejä, joka pilaisi hyökkäyksen.

Sovelluksen pitäisi palauttaa virheilmoitus, jossa on tieto, jonka haluat nähdä.

Kirjaudu järjestelmänvalvojana sisään.

Tässä labrassa tutustut syvemmin ORDER BY -lausekkeeseen, saat lisää harjoitusta alikyselyiden käytöstä, ja ennen kaikkea pääset harjoittelemaan virhepohjaista SQL-injektiotekniikkaa.

MySQLi ORDER BY Virhepohjainen Tekniikka

## ORDER BY

SQL:n ORDER BY -lauseke, kuten olet jo UNION-tekniikkaan tutustuessa oppinut, lajittelee tietokannasta palautuneet rivit joko sarakkeen nimen tai järjestysnumeron (ordinal) perusteella. ORDER BY ottaa lisäksi suuntaparametrin, jonka arvo voi olla ASC (ascending = nouseva) tai DESC (descending = laskeva).

Esimerkiksi tällainen kysely hakisi kaikki rivit tuotteet-taulusta ja lajittelisi ne hinnan mukaan nousevassa (halvin ensin) järjestyksessä:

```sql
SELECT * FROM tuotteet ORDER BY hinta ASC
```

---

## Injektio

Mutta entäs jos SQL injektio onkin ORDER BY -lausekkeessa? Tällaista haavoittuvuutta esiintyy melko usein, kun sovellukset esimerkiksi antavat käyttäjän järjestää taulukon tietyn sarakkeen mukaan.

Otetaan käytännön esimerkki tutusta verkkopankista. Kontaktilistauksen voi lajitella etunimen, sukunimen, sähköpostin tai tilinumeron perusteella.

![](sanity:image-012eacc28a003db157ddb6f488ccddad587c1a86-842x252-png)

Sovellus ottaa lajitteluparametrin query-parametrina (URL-osoitteesta) ja käyttää parametria rakentamaan SQL-kyselyn.

![](sanity:image-38f6779da0d98bd6b3f0632535619a475fa800da-397x64-png)

```sql
SELECT * FROM user ORDER BY email ASC
```

Mitä tapahtuu jos sovellus on haavoittuva SQL -injektiohyökkäyksille ja hyökkääjä antaakin sort-parametrin arvoksi "**email UNION SELECT username, password FROM users-- **"?

Hyvä idea! Valitettavasti kuitenkaan...

---

## UNION ei toimi

SQL-syntaksi ei salli UNION-lausekkeita enää ORDER BY jälkeen. Toisin sanoen, injektiopiste on liian myöhään SQL-kyselyn rakenteessa, jotta voisimme enää käyttää UNION-tekniikkaa. Voit toki kokeilla! Mutta näin siinä käy: 

![](sanity:image-e34544bd7c14c04a63883f1c74791a6b5aa9fd50-683x214-png)

Joudumme siis turvautumaan hieman luovempaan, niin kutsuttuun virhepohjaiseen tekniikkaan.

---

## Virhepohjainen tekniikka

Virhepohjaisen tekniikan perusidea on seuraavanlainen: 

- Rakennetaan tahallaan SQL-kysely, joka aiheuttaa virheen.
- Huolehditaan, että virhe sisältää tiedot, joita halutaan tietokannasta viedä.
- Tuodaan virhe meidän (hyökkääjän) näkyville.

Onnistuakseen virhepohjainen tekniikka vaatii siis että sovellus palauttaa tekniset virheilmoitukset sellaisenaan palvelimelta selaimelle meidän nähtäväksi. Tämä on yksi syy, miksi tietoturvatarkastajat muistavat aina huomauttaa sovelluksen virheidenhallinnan tärkeydestä. Virheiden vuotaminen tekee haavoittuvuuksien löytämisestä ja hyväksikäyttämisestä merkittävästi helpompaa, ja tässä tapauksessa ylipäätään mahdollista.

SQL-syntaksi sisältää monenlaisia funktioita. Olemme tähän mennessä tutustuneet vain concat-funktioon joka yhdistelee tekstiä. Nyt tutustumme toiseen funktioon, nimeltä ExtractValue, joka liittyy XML-käsittelyyn. Funktion "oikea" käyttötarkoitus ei ole tärkeä, mutta tässä on kuitenkin esimerkki siitä miten sitä olisi tarkoitus käyttää: 

```sql
EXTRACTVALUE('<autot><auto>Lada</auto></autot>', '/autot/auto')
-> Lada
```

Funktio siis ottaa ensimmäisenä parametrina XML:ää, ja toisena parametrina XPATH-valitsimen, jolla poimitaan tietoja XML:stä. Ei haittaa, jos et tiedä mitä XML ja XPATH ovat, opit niistä toisella kurssilla. Oleellista on, että ***ExtractValue****-funktio aiheuttaa epäonnistuessaan virheen, joka tulostaa XPATH-valitsimen*.

```sql
SELECT EXTRACTVALUE(0, "<VIRHEELLINEN")
```

![](sanity:image-21e9c4a0e9517aebdf5a50f3aab200a4ff2d3f07-644x86-png)

Miten siis saisimme XPATH-valitsimen arvon sisältämään sekä **<** -merkin (joka aiheuttaa tarvittavan virheen) että mitä tahansa mitä tietokannasta halutaan nähdä? Tietysti **CONCAT**-funktiolla, yhdistämällä **<** -merkin ja alikyselyn! Molempien (**concat** ja alikyselyt) pitäisi olla sinulle jo tuttuja.

```sql
EXTRACTVALUE(0, CONCAT("<", (SELECT @@version)))
```

![](sanity:image-66a81bce7b43297a3878824f8ca845df31a3da42-576x83-png)

---

## Mutta mihin kohtaan ExtractValue tulee?

Yksi helppo vaihtoehto on tehdä **ORDER BY** -kyselylle toinen lajitteluparametri. **ORDER BY -**syntaksi tukee useampaa parametria, esimerkiksi näin: Kysely listaisi tuotteet hinnan mukaan järjesteltynä, ja niistä, joiden hinta on sama, näytettäisiin ensin ne, jotka ovat varastossa.

```sql
SELECT * FROM tuotteet ORDER BY hinta, varastossa
```

Voimme laittaa alikyselyn toiseksi järjestysparametriksi, näin: 

```sql
SELECT * FROM tuotteet ORDER BY hinta, (SELECT ExtractValue(...))
```

---

## Summaus

- Lisää kyselyyn uusi **ORDER BY** -lajitteluparametri (eli pilkku edellisen perään), ja laita sen arvoksi uusi alikysely.
- Kommentoi loput kyselystä ulos (**-- **).
- Muodosta alikysely niin, että se käyttää ExtractValue-funktiota, ensimmäisenä parametrina vaikka numeroa **0** (tällä ei ole juurikaan väliä), ja toisena parametrina **CONCAT**-funktiokutsua, joka puolestaan ottaa ensimmäisenä parametrina **<** -merkin ja toisena parametrina alikyselyn, joka hakee tiedot joita haluat nähdä.
- Tiedot, jotka haluat nähdä, ovat **CONCAT(email, ":", password) FROM user WHERE admin=True LIMIT 1 **eli sähköposti ja salasana ensimmäiseltä admin-käyttäjältä, varmistaen **LIMIT**-lausekkeella ettei alikysely palauta ylimääräisiä rivejä, joka pilaisi hyökkäyksen.
- Sovelluksen pitäisi palauttaa virheilmoitus, jossa on tieto, jonka haluat nähdä.

@exercise 3893f283d18c


(MySQL) ORDER BY ja Virhepohjainen Tekniikka

SQL-injektio lienee syynä valtaosaan vakavista tietomurroista, pääasiallisesti sen takia että haavoittuvuus on suuressa sovelluksessa erittäin todennäköinen jos teknologiavalinnat ovat huonot, ja seuraus on yleensä koko tietokannan vuotaminen hyökkääjälle.

(MySQL) ORDER BY ja Virhepohjainen Tekniikka

ORDER BY

Hakkeroinnin oppiminen alkaa tästä