Esijulkaisin educational purposes -mielessä pienen (15 kysymystä) sisältävän "tietovisan" liittyen webbiohjelmoinnissa vastaan tuleviin tietoturva-asioihin:
http://timoh6.github.io/WebAppSecQuiz/
Kysymyksiä on laidasta laitaan (täysin perusasioista hieman monimutkaisiin/harvinaisempiin kokonaisuuksiin), esimerkkikoodit ovat PHP:tä ja pseudokoodia.
Käykää kokeilemassa miten tuttua asiaa kysymykset ovat, ja jos ei muuta, niin palaute aina kelpaa.
Alla on palautetta ja spoilereita, älä lunttaa!
Kysymys 5 (prepared statements): Mielestäni on harhaanjohtavaa kysyä parametrisoitujen kyselyiden turvallisuudesta ja vaatia vastaukseksi ”ei, koska joskus ei käytetä parametreja”. Toki vastaus on selvä, kun on esimerkkikin annettu, mutta yhtä hyvin voisi olla oikeana vastauksena vaihtoehto ”ei, jos käytät niitä näin: prepare("... WHERE i = {$i}")”. Ja toisaalta kaikista kyselyistä kuitenkin oikealla käsittelyllä saa turvallisia riippumatta siitä, käytetäänkö parametrisointia vai muita tapoja, joten kysymys on sinänsä väärässä ja epäolennainen.
Kysymys 8: PHP:n htmlspecialchars ei oletusarvoisesti edes muuta '-merkkiä.
Kysymys 10 (POST-data tietokantaan): Mainitset merkistöt. Onko POST-data tässä todellakin tarkoitus tallentaa tekstisarakkeeseen eikä esimerkiksi BLOB-tyyppisenä? Miksi ihmeessä? Entä oletko huomioinut, että POST-taulukosta ei voi luotettavasti luoda alkuperäistä syötettä (esim. koodaamattomana lähetetyt merkit ja PHP:n ”korjaukset”) ja että multipart/form-data ei ole PHP:ssä saatavilla edes php://input-virran kautta? Toki nämä ovat epäolennaisia asioita, jos lokitaulun tarkoitus on auttaa vain PHP-koodin bugeissa eikä palvelinohjelmistojen bugeissa.
Kysymys 12 (104-bittinen salasana): Olen hieman yllättynyt, että olemme vastauksesta samaa mieltä. Aiemmista keskusteluista olen saanut kuvan, että sinusta mikään alle 128-bittinen salasana ei ole turvassa, jos MD5-tiiviste vuotaa.
Kysymys 13 (x.php.png): Kylläpä Apache on typerä palvelin. Olen joskus ihmetellyt, miten ihmeellisesti palvelin pitää konfiguroida, että saa tehtyä tuollaisen järjenvastaisen tietoturva-aukon. Näköjään se onkin hyvin helppoa.
Kysymys 14 (DOMDocument, loadXML): Millaista hyökkäystä tässä haet?
5. kysymyksessä taustalla on muistuttaa että tosiaan "prepared statements" ei ole silver bullet kaikkialla sql-lauseisiin. Kieltämättä kysymyksen olisi voinut muotoilla paremmin.
Htmlspecialchars ei tosiaan enkoodaa '-merkkiä, hyvä huomio. Lisään sen esimerkkiin.
10. kysymyksessä haetaan probleemaa "max_packet_size" -asetuksen kanssa. Eli kysely tippuu jos tuo raja ylittyy. Täytyy tarkentaa kysymystä.
Apachen AddHandler on tosiaan täysin väärä asetus, mutta silti se jostain syystä on mm. CentOS:ssa oletuksena noin (vastoin kaikkia suosituksia).
14. kysymyksessä on taustalla XML-parsintaan liittyvät ominaisuudet. Lähinnä "external entity injection". Mm. täällä on asia hyvin esillä:
http://phpsecurity.readthedocs.org/en/latest/
timoh kirjoitti:
10. kysymyksessä haetaan probleemaa "max_packet_size" -asetuksen kanssa. Eli kysely tippuu jos tuo raja ylittyy.
Ahaa. Tätä ongelmaa ei onneksi ole, jos PHP:n post_max_size on pienempi kuin MySQL:n max_allowed_packet.
timoh kirjoitti:
14. kysymyksessä on taustalla XML-parsintaan liittyvät ominaisuudet. Lähinnä "external entity injection".
Kiinnostavaa. Ajattelin ensin xincludea, mutta se pitäisi erikseen pyytää. Ehdin jo kirjoittaa tähän, että nuo SYSTEM-entiteetit eivät toimi, mutta toisella palvelimella ne näköjään toimivatkin vielä. Tilannetta on parantanut libxml 2.9.0:n muutos ”Do not fetch external parsed entities”.
Aivan, tosiaan external entities on muutettu oletuksena offille libxmls:ssä, good!
Sitten vielä pahoittelut liittyen ensimmäiseen kysymykseen "Input validation should be based on....".
Tässä tietysti oikea vastaus on "Whitelisting", eikä blacklisting, mikä virheellisesti oli oikeaksi vastaukseksi eksynyt. Se on nyt fixattu.
Olikin jo wtf-olo tuon ekan kysymyksen päällisiä.
Lisäsin tietovisan oikeat vastaukset kommenttien/selitysten kera sivulle:
http://timoh6.github.io/WebAppSecQuiz/answers.
Aihe on jo aika vanha, joten et voi enää vastata siihen.