[SEC] Hoe implementeer je een veilige webapplicatie

[Verwijderd]

...

[ Voor 99% gewijzigd door Verwijderd op 23-05-2018 15:47 ]

[trinite_t]

Verwijderd schreef op vrijdag 20 februari 2009 @ 15:37:
Invoervalidatie

Alle informatie wordt met htmspecialchars() en addslashes() behandt. Mocht de informatie door moeten naar de database dan gebruik ik nog extra: mysql_real_escape_string()

Error handling
Standaard geef ik zo min mogelijk informatie prijs. Alle 400, 401,402,403,404,405 worden naar de homepage doorgestuurd. Daarnaast staat error_reporting altijd op 0. Behalve op test servers.

Hashing
Het lieft gebruik ik geen Md5 of sha1 maar RIPEMD-320 omdat de scriptkiddie dit algoritme hopelijk niet herkent en er nog niet zoveel crackers voor zijn. Daarnaast Salt ik wachtwoorden dus hash(wachtwoord + salt) = (dit wordt opgeslagen in de database).

Rechten

De webserver draait onder een appart hiervoor gemaakt account

Invoervalidatie:
Laat dat door je db laat afhandelen, zelf gebruik ik prepared statements waardoor alles wat ik alles als parameters mee geef aan m'n query functie. Hierdoor bevat de query alleen maar ? op punten waar data van de gebruiker staat, en valt sql injectie zowieso al af.

Error handling:
Vindt google erg leuk. Geef gewoon een 404. Je kunt hieraan net zo goed zien dat er geen bestand staat. En als ze niet zo snugger zijn is het nog steeds security by obscurity

hasing:
evenzo, security by obscurity. Zowiezo, als je db gekraakt is kunnen ze toch al alle data aanpassen.

rechten:
Elke gebruiker draait scripts onder zijn eigen account (fcgi met suexec wrapper). Hierdoor kan ik per gebruiker configs wijzigen. Verder kan een gebruiker buiten zijn homedir hierdoor niets uitvreten.

[ Voor 9% gewijzigd door trinite_t op 20-02-2009 16:16 ]

[JayVee]

Verwijderd schreef op vrijdag 20 februari 2009 @ 15:37:
Invoervalidatie
Alle informatie wordt met htmspecialchars() en addslashes() behandt. Mocht de informatie door moeten naar de database dan gebruik ik nog extra: mysql_real_escape_string()

Outputvalidatie
Alles wat naar de site wordt geschreven wordt zowiezo met htmlspecialchars behandled

Volgens mij is deze shotgun-aanpak overdreven en gaat het niet eens goed werken. Escapen van variabelen is afhankelijk van de context. Een GET waarde die in de db terecht komt moet je SQL-escapen (dmv addslashes of mysql_real_escape_string), komt het in HTML terecht HTML-escapen (dmv htmlspecialchars), etc.
Gewoon alles escapen (a la magic_quotes) lijkt mij een slecht idee omdat je vaak zult moeten unescapen (bijv. als je een variabele in een javascript string wilt plaatsen - anders wordt '<' als zodanig weergegeven!)

Ik vind escapen ook een van de lastigste klussen, omdat je constant moet beslissen wanneer je escaped, en hoe je het moet doen. Gewoon alles dubbel escapen lost de meeste problemen misschien op, maar zorgt voor nieuwe problemen...

[ Voor 0% gewijzigd door JayVee op 20-02-2009 16:39 . Reden: gr, GoT escaped mijn input niet! ]

[Janoz]

Invoervalidatie

Alle informatie wordt met htmspecialchars() en addslashes() behandt. Mocht de informatie door moeten naar de database dan gebruik ik nog extra: mysql_real_escape_string()

Onzin... Data moet je escapen voor de toepassing, niet in het wilde weg wat escape functies aan lopen roepen. Dat het nu waarschijnlijk nog goed gaat is meer geluk dan wijsheid.

Outputvalidatie

Alles wat naar de site wordt geschreven wordt zowiezo met htmlspecialchars behandled

Bij het afdrukken op een html pagina zul je inderdaad html special chars er overheen moeten halen, maar in jou geval had je dat bij de input ook al gedaan waardoor de boel waarschijnlijk dubbel geescaped op de pagina terecht komt.


Samenvattend:
Escape voor de toepassing. Gaat het de database in, dan mysql_real _escape_string, of prepared statements gebruiken (dus niet allebei tegelijk!). Schrijf je het naar een bestand? Dan hoeft er helemaal geen escaping overheen. Zet je het in je html pagina, dan html special chars ed.

-edit- Wat hierboven dus ook allemaal gezegd wordt

Sessions
Om sessi hijacking te voorkomen geef ik ze niet mee aan de url parameters. Tenzij dit onvermijdelijk is. Daarnaast koppel ik een sessie aan

- Het ipadres (dus mocht de sessie gekaapt worden kan deze niet zonder spoofing worden overgenomen)
- Een timestamp (zodat deze sneller verloopt als er niks mee gebeurt).

Het is nogal onzin om in je sessie zelf weer een timestamp te gaan zetten. Pas daarvoor gewoon de properties van de sessie aan. Daar kun je de sessietijd verlagen. Daarnaast kun je de garbage collector kans verhogen zodat sessions sneller weggegooid worden.

[ Voor 24% gewijzigd door Janoz op 20-02-2009 16:44 ]

[418O2]

Kan dit niet beter in programming ?

trinite_t schreef op vrijdag 20 februari 2009 @ 16:10:
[...]

hasing:
evenzo, security by obscurity. Zowiezo, als je db gekraakt is kunnen ze toch al alle data aanpassen.

een reden voor hashing kan ook zijn dat je in het geval van een kraak de wachtwoorden van gebruikers niet verliest.

[Verwijderd]

...

[ Voor 97% gewijzigd door Verwijderd op 23-05-2018 15:48 ]

[Domokoen]

Verwijderd schreef op vrijdag 20 februari 2009 @ 16:58:
Een andere optie voor input,output validatie is werken met een whitelist,

regex"^[a..zA..Z0..9];

Als de variabele daaraan voldoet mag je verder, en krijg je een 404 oid

Met als nadeel dat iedereen die speciale tekens in zijn naam heeft niet door de validatie komt...

[Janoz]

Verwijderd schreef op vrijdag 20 februari 2009 @ 16:58:
@Catch22
Nee daar is die gesloten.

Een andere optie voor input,output validatie is werken met een whitelist,

regex"^[a..zA..Z0..9];

Als de variabele daaraan voldoet mag je verder, en krijg je een 404 oid

Hij is in PRG gesloten omdat dubbelposten niet de bedoeling is.

[doeternietoe]

Verwijderd schreef op vrijdag 20 februari 2009 @ 15:37:
Invoervalidatie

Alle informatie wordt met htmspecialchars() en addslashes() behandt. Mocht de informatie door moeten naar de database dan gebruik ik nog extra: mysql_real_escape_string()

Ik zou gerichte inputvalidatie doen en niet alles maar door de functies die je noemt halen. Dan krijg je ranzige constructie waarbij je later de functie weer ongedaan moet maken of je geeft jezelf schijnveiligheid.

Outputvalidatie

Alles wat naar de site wordt geschreven wordt zowiezo met htmlspecialchars behandled

Opnieuw, doe dit soort dingen gewoon gericht. Denk er bij ieder onderdeel over na in plaats van het zo in het wilde weg toe te passen.

Error handling
Standaard geef ik zo min mogelijk informatie prijs. Alle 400, 401,402,403,404,405 worden naar de homepage doorgestuurd. Daarnaast staat error_reporting altijd op 0. Behalve op test servers.

En vervolgens houdt je je niet aan de webstandaarden. Dat gaan zoekmachines die de site indexeren ook leuk vinden. Als je slechts een index.php hebt waar gebruikers recht op hebben, en verder niets, wat is er dan in vredesnaam mis met het genereren van een fatsoenlijke 404? Je moet geen veiligheidsmaatregelen gaan nemen die niets aan de veiligheid toedoen.

Hashing
Het lieft gebruik ik geen Md5 of sha1 maar RIPEMD-320 omdat de scriptkiddie dit algoritme hopelijk niet herkent en er nog niet zoveel crackers voor zijn. Daarnaast Salt ik wachtwoorden dus hash(wachtwoord + salt) = (dit wordt opgeslagen in de database).

Security through obscurity is géén oplossing. Het RIPEMD-320 algoritme heeft als belangrijk nadeel dat het door veel minder mensen is getest dan MD5 en SHA1. Wie weet is dat algoritme wel veel kwetsbaarder. Als je dan toch een hashing algoritme gebruikt, doe dan een latere versie van SHA. Van de 512 bit variant zijn voorzover ik weet nog geen collisions bekend.

SSL
Dit gebruik ik zelfden (eigenlijk te weinig). Voornamelijk omdat klanten het teveel sores vinden om de certificaten aan te vragen.

Right tool for the right job. SSL is een beveiliging tegen een man-in-the-middle-attack, niet tegen hackers. Als je een tamelijk statische website hebt waarbij geen gevoelige (inlog)gegevens worden verstuurd, dan voegt het weinig toe. Het kost daarentegen wel veel in zowel financieel opzicht als in termen van tijd en moeite.

Sessions
Om sessi hijacking te voorkomen geef ik ze niet mee aan de url parameters. Tenzij dit onvermijdelijk is. Daarnaast koppel ik een sessie aan

- Het ipadres (dus mocht de sessie gekaapt worden kan deze niet zonder spoofing worden overgenomen)
- Een timestamp (zodat deze sneller verloopt als er niks mee gebeurt).

Hoe ga je het ip-adres bepalen? Veel gebruikers internetten vanachter een proxy, waarbij per aanvraag hun remote ip kan wisselen. Als gebruikers om de vijf klikken/per ip-adres opnieuw moeten inloggen gaat de veiligheid er ook niet echt op vooruit. Als je het ip-adres bepaald aan de hand van de X-FORWARDED-FOR http-header dan heb je zojuist een nieuwe schijnveiligheid geïntroduceerd. Iedere beginnende hacker kan simpel de header zelf aanpassen.

Hebben jullie nog aanvullingen om (web)applicatie beveiliging verder uit te breiden?
Ook de paranoid opties zijn welkom en interessant

Aangezien je erom vraagt:
- Belangrijkste punt mis ik nog: Denk goed over iedere keuze na. Als ik je verhaal nu lees dan lijkt het erop alsof je in het wilde weg allemaal functies toepast die je het idee van veiligheid geven (addslashes/htmlspecialchars/etc), zonder er over na te denken waarom je die gebruikt en wáár je ze moet gebruiken. Maak bewust een ontwerp in plaats van met deze functies te smijten
- Tevens: verplicht je gebruikers tot veilig gedrag. Specificeer bijvoorbeeld een minimale wachtwoordlengte.

Als je toch paranoide bent:
- Maak voor iedere gebruiker een unieke, lange salt. Een specifiek voor jouw site en jouw salt gemaakte dictionary-attack gaat in dat geval niet werken
- Verplicht gebruikers tot het gebruiken van extreem lange wachtwoorden met combinaties van alle mogelijke tekens. (De paranoide variant van hierboven.)
- Valideer gebruikers bij iedere loginpoging door middel van een code die je per sms aan hen toe stuurt. Het is misschien ook nuttig om iedere maand de wachtwoorden te wijzigen en de nieuwe wachtwoorden per aangetekende post op te sturen.
- Regel gewapende beveiliging pal voor het rack waar je server inhangt. Het zou wat al te simpel zijn als iemand fysiek op de server toegang kon krijgen.
- Etc

Het punt is denk ik duidelijk: Als je paranoide bent kun je wel de gekste dingen doen, maar het voegt weinig toe. Als je niet paranoide bent, kun je nog steeds gekke dingen doen, maar als je niet ontzettend goed begrijpt hoe het werk en waarom je het doet, dan helpt het nog heel weinig.

[trinite_t]

418O2 schreef op vrijdag 20 februari 2009 @ 16:42:
Kan dit niet beter in programming ?

[...]

een reden voor hashing kan ook zijn dat je in het geval van een kraak de wachtwoorden van gebruikers niet verliest.

Ik ben zeke rmet je eens dat je je wachtwoorden hashed, maar daarvoor hoef je geen 'obscuur' hash algoritme gebruiken zoals RIPEMD-320. md5 of sha1 is, mits je een goede salt gebruikt net zo goed.
En de reden waarom de TS dit algoritme gebruikt IS security by through obscurity.

[Verwijderd]

...

[ Voor 98% gewijzigd door Verwijderd op 23-05-2018 15:48 ]

[serkoon]

Een paar dingen: Waarom zou je MD5 of SHA1 gebruiken (waarvan met name MD5 al geruime tijd rammelt) terwijl er prima alternatieven zijn die waarschijnlijk nog wel een tijdje mee kunnen en niet duurder of moeilijker te implementeren zijn? De halve wereld stapt juist van met name MD5 maar ook al SHA1 af en niet voor niks. (waarbij ik op wil merken dat de huidige attacks zich vnl richten op het veroorzaken van collissions ipv het 'kraken' van een hash, maar toch)

Ten tweede, vergeet vooral autorisatie-checks niet! Erg veel webapps gaan nog de mist in wat betreft autorisatie-controles. Probeer een rollen/autorisatie-structuur op te zetten die centraal te programmeren is maar toch voor elk stukje functionaliteit werkt. Ga uit van het principe 'deny unless explicitly allowed', zodat een gemiste check ervoor zorgt dat de functionaliteit gewoon niet werkt.

Wat betreft invoervalidatie, pas die toe op het soort invoer dat je verwacht. Verwacht je een naam, sta dan karakters toe die in een naam horen voor te komen. Daar kan een apostrof bij zitten waar je database-queries van over de zeik kunnen gaan: invoervalidatie sluit prepared statements met parameter binding niet uit. Voor getallen doe je 0-9 en gebruik je eventueel een onder- en bovengrens, enzovoort. Pas ook dit generiek toe, anders wordt het een klote-klus en ga je geheid dingen over het hoofd zien.

Nog iets waar je webapps erg veilig van krijgt: gebruik geen absolute id's. Toon je wat data met wat items specifiek voor de ingelogde user, waarvan elk item opgevraagd kan worden op basis van het id? Geef de items een relatief id ten opzichte van de huidige tabel die getoond wordt ipv een absolute uit de db. Als iemand een absoluut id opvraagt, moet je een autorisatiecheck doen. Bij een relatief id hoef je alleen te checken of het id >=0 en <= len(resultset) (en als je de check vergeet krijg je hooguit een exception).

Als je app login- en/of persoonsgegevens betreft: SSL gebruiken. Ik ben't niet met doeternietoe eens dat dat duur zou zijn of veel moeite zou kosten. Een officieel cert kost vrijwel niks meer en is eenvoudig aangevraagd (eigenlijk te eenvoudig). Het configgen en gebruik ervan stelt ook weinig voor, hooguit is het wat vervelend dat je ergens bij moet houden dat je cert af en toe ververst dient te worden. Daar kan je cert-verkoper je ook gewoon een seintje voor geven, overigens.

[Equator]

trinite_t schreef op vrijdag 20 februari 2009 @ 19:29:
[...]


Ik ben zeke rmet je eens dat je je wachtwoorden hashed, maar daarvoor hoef je geen 'obscuur' hash algoritme gebruiken zoals RIPEMD-320. md5 of sha1 is, mits je een goede salt gebruikt net zo goed.
En de reden waarom de TS dit algoritme gebruikt IS security by through obscurity.

Dat jij het algoritme niet kent, betekent niet dat het een obscuur algoritme betreft.

RIPEMD-160 bestaat al sinds 1996, en er zijn geen gekke dingen over bekend.

MD5 zou ik iig niet meer gebruiken. Zonder salting al helemaal niet meer.

Persoonlijk zou ik voor SHA-160 of SHA-256 bit kiezen. ben je echt paranoide dan is SHA-384 misschien meer je smaak. SHA-512 biedt geen extra veiligheid aangezien deze dezelfde blocksize en Internal state size gebruikt als 384. Alleen de output is langer.
En natuurlijk salt je je hashes

[CubicQ]

Nuttige achtergrond informatie over het bouwen van veilige webapplicaties is trouwens te vinden op de pagina van OWASP: http://www.owasp.org/index.php/Main_Page

Zeker hun Top-Ten documentatie is erg de moeite waard. Daarin identificeren ze de 10 belangrijkste 'fouten' bij het maken van een veilige webapplicatie en beschrijven ze wat je er tegen kan doen.