NGI-lezing: Hoe veilig is uw website?

NGI-lezing: “Hoe veilig is uw website?” De kwaliteit van websites van geborgd Hans de Goede Leo van Koppen Marcel Spruit

Stand van zaken informatiebeveiliging Verantwoordelijkheid voor Informatiebeveiliging? Systeem- /netwerkbeheerders Security officer /manager (CISO of IBF)

Applicatieontwikkelaars, beheerders en managers ? Ook zij zouden zich meer verantwoordelijk moeten voelen voor de betrouwbaarheid van een (web)applicatie. Betrouwbaarheid is een kwaliteitsaspect van de software. Wat definieer je dan als software?

nr.: 2

HHS/THR

Lectoraat informatiebeveiliging

2006

1

Definitie Informatiebeveiliging = Het treffen en onderhouden van een samenhangend pakket maatregelen om de betrouwbaarheid van de informatievoorziening te waarborgen Betrouwbaarheid Beschikbaarheid

A vailability

Integriteit

I ntegrity

Vertrouwelijkheid

C onfidentiality

…en dat bepaalt mede de scope van het volgende betoog.. nr.: 3

HHS/THR


2006


2006

Scope Referentiemodel webapplicatie

Bron:The OpenGroup Architecture Framework Reference model

nr.: 4

HHS/THR

2

Agenda (bijdrage Hans de Goede) Scope Betrouwbaarheid TRM-model

Softwareontwikkeling OWASP kwetsbaarheden top10 Veiligheid tijdens het ontwerp Veiligheid tijdens de implementatie User input validatie Errorhandling

Aandacht voor kwaliteit Attitude van de programmeur Veiligheid tijdens testen Veiligheid tijdens het gebruik

nr.: 5

HHS/THR


2006

Kritische webapplicaties (OWASP top 10)

nr.: 6

HHS/THR


2006

3

Veiligheid tijdens het ontwerp (1) Scheiden code en data (A4, A6) Bijv: geen javascript invoer toestaan in HTML invoer.

Simplicity (A1 - A10) Principal of Least Privilege (A2) Authenticatie en Authorisatie: Liefst meer dan 1 test conditie voor toegang. (A2, A3) Bijv: voor Adminstrators en een certificaat en een usernaampassword. Bijv: voor sommige acties en de nodige gebruikersrechten en alleen vanaf bepaalde locaties.

nr.: 7

HHS/THR


2006

Veiligheid tijdens het ontwerp (2) Controleer alle toegangs paden naar een te beschermen object (A2) Bijv: Niet alleen de bij de hoofdadministratie pagina de gebruikers identiteit controleren maar ook bij allen achterliggende pagina's! Bijv: Als gewone pagina's een “edit-mode” hebben niet alleen controleren op aanwezigheid van een edit (get/post) parameter maar ook of de gebruiker edit rechten heeft!

Geen “security by obscurity” (A8) Bijv: Als enkel de authenticatie via SSL plaatsvindt, en vervolgens de credentials gecrypt worden opgeslagen in een cookie geen eigen encryptie verzinnen, maar een bestaande bewezen gebruiken. nr.: 8

HHS/THR


2006

4

Veiligheid tijdens de implementatie, user input validatie (A1) Ga niet uit van wat niet mag worden ingevoerd maar van wat wel mag (en moet!) worden ingevoerd (Least Privilige). Controleer user input op alle lagen: Browser (javascript) PHP/ASP code, een kwaadwillende kan immers de browsercheck omzeilen (Controleer alle toegangspaden). Database d.m.v. integrity constraints (DOMAINS, KEY, ASSERTION)

Escape altijd (zelfs van gevalideerde input!) bijzondere characters d.m.v. de gegeven bibliotheek functies. Dit voorkomt injectie (A6) en crossscripting (A4) aanvallen. nr.: 9

HHS/THR


2006

Veiligheid tijdens de implementatie, Errorhandling (A7) Vrijwel elke bibliotheek aanroep geeft een status code terug, controleer deze altijd! Geef alvorens te stoppen met je processing eerst eventueel gealloceerde resources (bijv: databaselocks!) vrij. (A9) Toon altijd een eigen foutmelding i.p.v. te vertrouwen op de foutafhandeling van de scripttaal, scriptinterperter gegenereerde fouten kunnen waardevolle informatie voor aanvallers bevatten!

nr.: 10

HHS/THR


2006

5

Aandacht voor kwaliteit, Attitude van de programmeur Veel programmeurs zondigen tegen de regels gegeven op de “Veiligheid tijdens de implementatie” sheets. Argument: “Dat kost teveel tijd en die krijg / heb ik niet.” Dit argument is onjuist als deze aanbevelingen tijdens de eerste implementatie direct worden meegenomen kosten deze nauwelijks tijd en zullen zij bovendien tijdens de eerste testen zoveel problemen voorkomen / verhelderen dat deze aanbevelingen uiteindelijk tijd opleveren!

nr.: 11

HHS/THR


2006

Aandacht voor kwaliteit, “Testen” M.b..v. “bijzondere” testen naast de standaard functionele test kan de betrouwbaarheid behoorlijk verhoogd worden: Peer Review (Open Source) Tools: Random input generation Sourcecode verificatie, bijv: phplint: http://www.icosaedro.it/phplint

Code Audit

nr.: 12

HHS/THR


2006

6

Voorbeeld: Code Audit Scorched3d, buffer overflows Foutieve code: char message[1024]; sprintf(message, "joined \"%s\" [%s]", tank->getName(), tank->getUniqueId());

Correcte code: char message[1024]; snprintf(message, sizeof(message), "joined \"%s\" [%s]", tank->getName(), tank->getUniqueId());

nr.: 13

HHS/THR


2006

Voorbeeld: Code Audit Scorched3d, injection (HTML) Foutieve code: players += formatString( “” ... "%s" // Name ... "\n", ... tank->getName(), Goede Code:

nr.: 14

HHS/THR


2006

7

Voorbeeld: Code Audit Scorched3d, injection (HTML) std::string cleanName; std::string dirtyName(tank->getName()); XMLParser::removeSpecialChars(dirtyName, cleanName); players += formatString( “” ....... "%s" // Name ....... "\n", ........ cleanName, nr.: 15

HHS/THR


2006

Aandacht voor kwaliteit, gebruiksfase Gebruik filters in het applicatieplatform die potentieel gevaarlijke requests stoppen voordat ze bij de applicatie aankomen, de zogenaamde applicatie level firewalls. Bijv: ModSecurity voor Apache (http://www.modsecurity.org/) Schrijf en test tijdens de ontwikkeling al op de applicatie toegesneden filter regels (en lever deze mee aan de klant).

nr.: 16

HHS/THR


2006

8

Agenda (bijdrage Leo van Koppen) Kwaliteit Systeemontwikkeling Requirements Systeemarchitectuur Hoe te testen

Kennis (bewust bekwaam) Opleidingen Attitude van de ontwikkelaar

Aanbevelingen Conclusies nr.: 17

HHS/THR


2006

t

nr.: 18

HHS/THR


2006

9

Oorzaken? Geen inputvalidatie Bufferoverflows Injection flaws Virus !

nr.: 19

HHS/THR


2006

Conclusie vanuit het voorgaande

(Web)applicatielaag is het nieuwe slagveld van de hacker De oorzaken (kwetsbaarheden) zijn bekend OWASP top 10

De te nemen oplossingen/maatregelen zijn voorhanden Er zijn tools beschikbaar die support kunnen leveren bij het adresseren/oplossen van het probleem

nr.: 20

HHS/THR


2006

10

Kwaliteit van software “Software quality is no better today than it was decades ago. In some cases it‘s worse” James Whittaker, IEEE, 2003

• Waarom gebeurt het dan toch iedere keer weer? • Zijn we zo hardleers? • “Mensen maken fouten”! • De WEBapplicatieontwikkelaar ligt onder vuur !

nr.: 21

HHS/THR


2006

We zondigen tegen (kwaliteits)regels vanwege.. “Time to market”

Onvoldoende aandacht voor:

“Kosten”

Opdracht

“Het is geen functionaliteit”

Requirements

Geen notie van (onbekwaam) Werkwijze c.q. methode “We doen ons best”

Systeemontwikkeling

“Zo doen we het altijd”

Architectuur

Gebrek aan motivatie

Opleiden Competenties

geen zin!

Het is niet de focus Ander aandachtsgebied nr.: 22

HHS/THR


Kennis Vaardigheden Attitude 2006

11

Software ontwikkeling Systeemontwikkelmethoden

nr.: 23

HHS/THR


Bron: blad Informatie maart 2006

2006

Software ontwikkeling Systeemontwikkelmethoden

nr.: 24

HHS/THR


2006

12

Kwaliteit ISO-norm (definitie) Het geheel van eigenschappen en kenmerken van een product of dienst, dat van belang is voor het voldoen aan gestelde eisen of vanzelfsprekende behoeften.

RUP “Quality by design” ontwerp + testen bij elkaar brengen

TMAP Dynamische dimensie Æ doet het systeem wat verwacht wordt? Statische dimensie Æ is het systeem eenvoudig aanpasbaar?

nr.: 25

HHS/THR


2006

Kwaliteitsattributen (vlg. TMAP) Dynamisch

Statisch

Beveiliging

Beheerbaarheid

Authenticatie + Autorisatie

Bruikbaarheid

Connectiviteit Flexibiliteit

Continuïteit Robuustheid + Bedrijfszekerheid

Controleerbaarheid

Herbruikbaarheid Geschiktheid (infrastructuur) Onderhoudbaarheid

integriteit

Testbaarheid

Functionaliteit Gebruikersvriendelijkheid Inpasbaarheid Performance nr.: 26

Zuinigheid HHS/THR


2006

13

Fouten

Bron: Informatie maart 2006 nr.: 27

HHS/THR


2006

Architectuur van de webapplicatie

3 lagen architectuur met verschillende “security patterns”

nr.: 28

HHS/THR


2006

14

Security patterns in webapplicaties Identificatie: login, userID, password, tokens, PKI, infrastructuur

Inkomend verkeer: filtering, policies op proxy, configuratie

Webhost security: hardening, patches, SSL, password files, cookies,

Servlet engine + EJB security Policies, property files

Database security Policies, database access, control lists nr.: 29

HHS/THR


2006

Hoe te testen? Fasering Voorbereiding

Î Fagan inspectie

Specificatie

Î testspecificatie technieken

Uitvoering

Î indirect meetbare kwaliteitsattributen

Afronding

Î checklist testmetrieken

Hulpmiddelen Checklists, beslissingstabellen Dataflow test Error guessing Real life test Semantische test nr.: 30

HHS/THR


2006

15

Opleiding Applicatieontwikkelaars

Website bouwers

Opleiding (I) Informatica

Opleiding CMD (VIA)

Focus

Focus:

Systeemontwikkeling

Communicatieboodschap

Applicatiebouw

Design

Functionaliteiten realiseren

Interactie (ergonomie)

Tools, platform en technieken

Tools, platform en technieken

Studio ONE

“LAMP”

Visual studio

Agile /Extreme

RUP

??

TMAP nr.: 31

HHS/THR


2006

Attitude van de ontwerper Aandacht gaat uit naar het realiseren van Functionaliteit Concept, design

Betrouwbaarheid is slechts een klein deel van de requirements…… Good practices zijn: Veilige defaults, simplicity Controle d.m.v. peer reviews Leren van de open source community

nr.: 32

HHS/THR


2006

16

nr.: 33

HHS/THR


2006

Kwaliteit open source software

Bron: Coverty “Measuring software quality” A Study of Open Source Software nr.: 34

HHS/THR


2006

17

Enkele slotconclusies (preventieve) maatregelen nemen in de vorm van: Werk volgens een architectuur, maak gebruik van standaard (bewezen) oplossingen Security aspecten in de requirements fase signaleren en in het ontwerp meenemen als eis (bewust bekwaam) Testmethoden toepassen en gebruikmaken van hulpmiddelen die beschikbaar zijn (checklists, tools, etc.) Leren van elkaar (open source gedachte) code reviews, openheid Gedisciplineerd, nauwgezet en systematisch werken Attitude van de programmeur is van groot belang ….zoals de attitude van de systeembeheerder (firewall beheerder) op de infrastructuurlaag

nr.: 35

HHS/THR


2006

Tot besluit (bijdrage Marcel Spruit) Requirements Ontwerp Bouw Testen Validatie en acceptatie Exploitatie nr.: 36

HHS/THR


2006

18

“De ketting is zo sterk als …”

Vergissen is menselijk

Alle begin is moeilijk

Al doende leert men

Niemand is volmaakt

Het beste paard struikelt wel eens

Met vallen en opstaan leert men lopen

Driemaal is scheepsrecht

Waar gehakt wordt vallen spaanders

Uit het oog, uit het hart

De pot verwijt de ketel dat hij zwart ziet

Het doel heiligt de middelen

Een leugen om bestwil

Een belofte in dwang duurt niet lang

De gelegenheid maakt de dief

Eens een dief, altijd een dief

Ieder ziet door zijn eigen bril

Geld dat stom is, maakt recht wat krom is

In het land der blinden is eenoog koning

Een kat in nood maakt rare sprongen

De beste stuurlui staan aan wal

...

nr.: 37

HHS/THR


2006

Balans Baten zichtbaar Stimulerend Continu

Productie

Beveiliging

Functionaliteit Time to market

nr.: 38

HHS/THR

Baten onzichtbaar Niet stimulerend Af en toe


Veiligheid Kwaliteit

2006

19

Dank voor uw aanwezigheid

NGI-lezing 23 maart 2006 Locatie: Academie voor ICT & Media te Zoetermeer

nr.: 39

HHS/THR


2006

20

NGI-lezing: Hoe veilig is uw website?

Recommend Documents