secure (web)applications?
in der heutigen zeit sprießen programme und webapplikationen wie pilze aus dem boden. sobald die applikation irgendwie funktioniert, wird sie releast - im zeitalter von web 2.0 gibt es die tollen logos mit einem kleinen "beta" dran.
nun ja - es wird uns auch meist so vorgelebt (zb verwendet microsoft seine user ja auch als beta-tester). die heutige zeit ist in diesem bereich so schnell-lebig, dass viele meinen, dass man es sich nicht mehr leisten kann die applikation zb ausreichend zu testen - oder von der anderen sichtweise: wenn die applikation wirklich fertig wäre, dann ist sie schon wieder veraltet.
ich weiß nicht, ob es allgemein so ist, aber in meinem fall trifft es zu: ich habe nie gelernt SICHER zu programmieren! ich habe zwar gelernt zu programmieren, aber der security-aspekt war meiner meinung nach nicht wirklich vorhanden. mein ganzes (noch kleines) security know-how habe ich mir selbst erlernen müssen.
warum schreibe ich nun diesen blogeintrag?
ich bin sehr froh, dass ich nun endlich mein fh-projekt (j2ee, jsp) zum laufen gebracht habe. es ist ein simples programm. man ruft es im browser auf und gibt in das eingabefeld die matrikelnummer ein (und drückt enter oder klickt auf den button). danach wird in der datenbank gesucht und, wenn ein eintrag gefunden wird, dieser angezeigt (also matrikelnummer, name und nickname). falls kein entsprechender eintrag gefunden wird, sieht man die meldung "no student found for [matrikelnummer]".
mein erster gedanke war gleich: "was wäre, wenn ich jemanden suche, der mit mir zu mc donalds geht?" natürlich habe ich sofort statt einer matrikelnummer going to mc donalds eingegeben - leider wurde keiner gefunden ;)
der nächste gedanke war: "OJE! XSS ALARM!" und die eingabe von <script>alert(/XSS/);</script> bestätigte dies!
hmm ... da im hintergrund eine datenbank ist und derzeit noch die eingabe direkt in die sql-query kommt, könnte auch eine sql injection erfolgreich sein - sie war es ;)
und die moral von dieser geschichte?
alle benutzereingaben sind BÖSE (bzw sollten als solches angesehen werden)!
ich habe 6 zeilen an code hinzugefügt, um die benutzereingabe zu überprüfen und somit die xss-attacke und sql-injection zu verhindern bzw erfolgreich abzufangen.
wer nun diesen minimalen aufwand bezüglich security weglassen will, der soll es von mir aus auch tun - it's your choice!
security muss nicht unbedingt komplex sein - keep it simple!
mfg mailo
nun ja - es wird uns auch meist so vorgelebt (zb verwendet microsoft seine user ja auch als beta-tester). die heutige zeit ist in diesem bereich so schnell-lebig, dass viele meinen, dass man es sich nicht mehr leisten kann die applikation zb ausreichend zu testen - oder von der anderen sichtweise: wenn die applikation wirklich fertig wäre, dann ist sie schon wieder veraltet.
ich weiß nicht, ob es allgemein so ist, aber in meinem fall trifft es zu: ich habe nie gelernt SICHER zu programmieren! ich habe zwar gelernt zu programmieren, aber der security-aspekt war meiner meinung nach nicht wirklich vorhanden. mein ganzes (noch kleines) security know-how habe ich mir selbst erlernen müssen.
warum schreibe ich nun diesen blogeintrag?
ich bin sehr froh, dass ich nun endlich mein fh-projekt (j2ee, jsp) zum laufen gebracht habe. es ist ein simples programm. man ruft es im browser auf und gibt in das eingabefeld die matrikelnummer ein (und drückt enter oder klickt auf den button). danach wird in der datenbank gesucht und, wenn ein eintrag gefunden wird, dieser angezeigt (also matrikelnummer, name und nickname). falls kein entsprechender eintrag gefunden wird, sieht man die meldung "no student found for [matrikelnummer]".
mein erster gedanke war gleich: "was wäre, wenn ich jemanden suche, der mit mir zu mc donalds geht?" natürlich habe ich sofort statt einer matrikelnummer going to mc donalds eingegeben - leider wurde keiner gefunden ;)
der nächste gedanke war: "OJE! XSS ALARM!" und die eingabe von <script>alert(/XSS/);</script> bestätigte dies!
hmm ... da im hintergrund eine datenbank ist und derzeit noch die eingabe direkt in die sql-query kommt, könnte auch eine sql injection erfolgreich sein - sie war es ;)
und die moral von dieser geschichte?
alle benutzereingaben sind BÖSE (bzw sollten als solches angesehen werden)!
ich habe 6 zeilen an code hinzugefügt, um die benutzereingabe zu überprüfen und somit die xss-attacke und sql-injection zu verhindern bzw erfolgreich abzufangen.
wer nun diesen minimalen aufwand bezüglich security weglassen will, der soll es von mir aus auch tun - it's your choice!
security muss nicht unbedingt komplex sein - keep it simple!
mfg mailo
mailo - 3. Mai, 19:00