image

Tien kenmerken van onveilige web applicaties

maandag 13 november 2006, 13:04 door Redactie, 14 reacties

Veel websites en applicaties zijn zo lek als een mandje. Uit onlangs gepubliceerd onderzoek blijkt dat cross-site scripting met 21,5% op alle sites het meest voorkomende beveiligingslek is. Ook andere kwetsbaarheden in applicaties, zoals SQL injectie (14%) en PHP includes (9,5%) zijn nog altijd in grote getalen aanwezig.

Michael Sutton heeft 10 kenmerken van onveilige applicaties gepubliceerd, zodat webontwikkelaars en webmasters zich kunnen afvragen of hun creaties wel veilig zijn.

1. Gebruik van lekke / verkeerde ingestelde statistiekenprogrogramma's.
2. Het laten staan van backup bestanden in de webdir.
3. Je site staat op de sla.ckers.org "Hall of Shame".
4. Open directories.
5. Het onversleuteld parsen van logingegevens.
6. Oude SSL certificaten.
7. Kwetsbare third party applicaties.
8. Verbose foutmeldingen.
9. Opmerkingen van de ontwikkeaar in de broncode.
10. Je bent gedefaced en staat in het Zone-H defacement archief.

Reacties (14)
13-11-2006, 13:23 door SirDice
Nummer 1 is toch wel het niet goed (server-side) valideren van de input..

Dat je niet op sla.ckers of Zone-H staat betekend nog niet dat je een veilige site hebt.. Je bent dan gewoon nog niet aan de beurt geweest..

Al deze punten zeggen helemaal niets over de veiligheid van je webapplicatie zelf..
13-11-2006, 13:44 door awesselius
Ik ben het met SirDice eens (wanneer niet?) dat de titel
voor de zoveelste keer en niet enkel op deze site niet de
lading van het artikel dekt.

Je spreekt van lekke applicaties als het om de bouw van de
code gaat en de manier waarop de functionaliteit wordt
afgehandeld.

Het lijstje somt meer op over de structuur van je webserver.
Als je dat verkeerd inricht dan kun je inderdaad voor leuke
onverwachte problemen kunnen te staan. Wat ook nog eens
flink wat geld kan kosten als je helemaal niet weet waar je
mee bezig bent, maar wel denkt professioneel te werken.

Ik kende sla.ckers.org niet, dus al met al weer wat geleerd.
BTW, ik ben geen full-time security officer of iets, dus is
dat niet zo raar.

- Unomi -
13-11-2006, 13:44 door wimbo
Een oud SSL certificaat wil nog niet zeggen dat je onveilige
webapplicatie heb. Liever een oud/verlopen SSL certificaat
dan helemaal geen SSL certificaat.
13-11-2006, 14:58 door SirDice
Door wimbo
Een oud SSL certificaat wil nog niet zeggen dat je onveilige webapplicatie heb. Liever een oud/verlopen SSL certificaat dan helemaal geen SSL certificaat.
Precies.. Een SSL certificaat is geen garantie dat de webapplicatie zelf veilig is. Ik ken genoeg SSL beveiligde sites die zo lek zijn als een mandje..
13-11-2006, 15:47 door Anoniem
Ik ben het met alle bovenstaande opmerkingen eens. Wel zijn de
genoemde punten indicatoren (die ook nog eens eenvoudig zijn na te
gaan) dat de beveiliging mogelijk onvoldoende is. Een XXS lek is geen
indicator, maar een feitelijk een lek.
13-11-2006, 23:10 door Anoniem
Ik mis php in het lijstje. Niet omdat dat opzich onveilig is
maar vaak zitten problemen wel in slecht geschreven
php-toepassingen.
14-11-2006, 09:48 door Anoniem
Door Anoniem
Ik mis php in het lijstje. Niet omdat dat opzich onveilig is
maar vaak zitten problemen wel in slecht geschreven
php-toepassingen.

Hmm dan kan je Java en alle andere programmeer talen er ook
onderzetten.

Probleem is denk dat veel MKB-ers tegenwoordig gebruik maken
van CMS zoals Joomla en Mambo waarbij veel componenten
gratis te krijgen zijn zonder dat de kwaliteit van deze
componenten duidelijk. Vaak ontbreekt er documentatie en
worden deze niet geupdated. Daarnaast is het makkelijk in
Google te zoeken naar dit soort CMS-en wat het voor de
script kiddies eenvoudiger wordt om bestaande hacks uit te
proberen (als ik kijk naar mijn logfiles gebeurd dit 2-4x
per maand). Veel systemen worden niet geupgrade door de
onbekendheid bij de eigenaars hoe dit moet .

Richard
14-11-2006, 10:08 door SirDice
Door Anoniem
Ik mis php in het lijstje. Niet omdat dat opzich onveilig is maar vaak zitten problemen wel in slecht geschreven php-toepassingen.
Niet alleen in php toepassingen hoor.. Ik ken ook genoeg ASP en ASP.NET sites die flink rammelen.. De taal waarin de site gemaakt is is niet zo heel relevant..
14-11-2006, 11:01 door Anoniem
En hier komt telkens keer op keer het punt tijd kost geld om de de hoek
kijken.Waneer gaan bedrijven nou eens een applicatie ontwikkelen door
een goed profecioneel bedrijf.Die applicaties blijven testen en patchen
voor de veiligheid voor de gebruiker.In plaats daarvan kiezen ze voor snelle
goedkope oplossingen en krijg je dit soort onodige situaties waardoor
webserver slecht geconfigureerd worden applicaties lekken als een
mandje en persoonlijke gegevens van gebruikers uitlekken.

Tevens vraag ik me af waarom het puntje de functies in asp en php en .net
niet worden genoemd want veel zijn ook kwetsbaar voor sql injectie of voor
buffer overflow.
14-11-2006, 12:16 door SirDice
Door Koekie
Tevens vraag ik me af waarom het puntje de functies in asp en php en .net niet worden genoemd want veel zijn ook kwetsbaar voor sql injectie of voor buffer overflow.
Dat is heel simpel af te vangen: Input validatie. Vertrouw echt helemaal niets wat de client naar de server stuurt. Filter wat je hebben wilt en stuur de rest naar de bitbucket..
14-11-2006, 12:59 door Anoniem
SirDice,
Wat gebeurd er eigenlijk bij Input validatie als ik zo vrij mag zijn? Dat totale
packetjes vervangen worden die aanvragen doen bij servers ?
14-11-2006, 14:18 door SirDice
We hebben het hier over webapplicaties.. Dus zaken als invoervelden controleren etc.. Als er een e-mail adres moet staan controleren of het ook iets is wat op een e-mail adres lijkt ( blah@blah.die.blah ). En als het iets anders is dan gooi je het weg..
14-11-2006, 16:03 door Anoniem
Ah op zo manier thx! Weer iets geleerd :-)))))
06-12-2006, 23:30 door Anoniem
Mee eens met de lijst, alleen valt er aan "defacement" soms
weinig te doen. Uit eindelijk kan elke site ge-defaced
worden mits er genoeg tijd in gestoken wordt.

- Jungsonn.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.