Brontekst bekijken van Ontwikkeling van veilige software

[[Afbeelding:FrankPiessens.jpg|right|200px|]]
=Samenvattingen=
[[Ontwikkeling van veilige software/Samenvattingen| Klik hier om de samenvattingen te bekijken]]

=Informatie over het examen=
Je vragen zo volledig mogelijk uitschrijven. Tijdens het mondeling leest hij die dan zorgvuldig na en begint dan zo veel mogelijk vragen te stellen om die kleine details die er nog bijhoorden ook eruit te krijgen.

=Examenvragen=

== 2013-2014 ==
=== 10 januari 2014 (namiddag) ===

*Verklaar volgende begrippen: 
*#Return-to-libc (doorvraag: hoe zou je hiermee meerdere keren kunnen terugkeren naar adres)
*#control flow integrity 
*#elevation of privilege 
*#clickjacking 
*#sandboxing

*XSS vs CCRF: leg beiden uit adhv (technish) gedetailleerd voorbeeld, vergelijk en bespreek verschillen. 
*Gegeven policy model over chinese wall (http://www.cs.utexas.edu/~byoung/cs361/lecture25.pdf). Gevraagd: construeer security automaton (zoals DAC)
* bespreking project indien onregelmatigheden (zoals laattijdig indienen of vermoedens van samenwerken)



=== 16 januari 2014 (voormiddag) ===
*Verklaar volgende begrippen: 
*#Software vulnerability
*#Elevation of privilege
*#Defacement
*#Non-repudiation
*#Second order injection

*CSRF aan de hand van een voorbeeld uitleggen, wat kan je er tegen doen?

*Leg in detail return-to-libc uit

== 2012-2013 ==
=== 17 januari 2013 (voormiddag) ===

*Verklaar volgende begrippen: 
*#adress space layout randomisation 
*#control flow integrity 
*#elevation of privilege 
*#clickjacking 
*# ...

*XSS vs CCRF: leg beiden uit adhv gedetailleerd voorbeeld, vergelijk en bespreek verschillen. 
*DAC met meerdere owners, geef automaat + voor en nadelen van meerdere owners vs 1 owner.
* bespreking project

=== 17 januari 2013 (namiddag) ===
*Cross-Site Request forgery: leg uit aan de hand van voorbeeld + geef mogelijke tegenmaatregelen
*Verklaar volgende begrippen: 
*#software vulnerability 
*#non-repudiation 
*#defacement 
*#elevation of privilege 
*#second order injection attack
*stuk code gegeven: Deze code bevat een buffer overflow vulnerability: Waar zit ze en hoe kan ze worden uitgebuit. Beschrijf gedetailleerd.
*bespreking practicum


==2010-2011==
=== 21 januari 2011 (namiddag) ===

* Project bespreken (+ bijvragen over het hele webapplicaties-gedeelte: bv. gebruik van tokens als oplossing voor CSRF) (5p)
* Security automaat geven voor volgend systeem (5p):
*# a) Je hebt users en multimediaobjecten die beschermd moeten worden. Je heb 2 operaties: pay(Resource r) waarbij een user een vast bedrag betaalt en zo de resource aankoopt ; en use(Resource r) waarbij de user de resource gebruikt. De informele policy is: een user die een resource betaald heeft via pay(..) mag een resource 10 keer downloaden/gebruiken via use(..). 
*#b) breid dit systeem uit, als je weet dat er ook een action transfer(integer n,user g1, user g2,resource r) is waarbij user g1 n van de downloadrechten van r die hij bezit afgeeft/doorgeeft aan user g2.

* (5p) Stukje code gegeven waarin een pointer en een buffer gedeclareerd zijn naeen, de buffer is 256 bytes groot en er wordt een strcpy in gedaan van een meegegeven argument. Erna wordt de functie van de pointer opgeroepen op het tweede argument.
Vraag: In deze code zit een buffer overflow vulnerability. Waar ? En beschrijf in detail hoe je die kan uitbuiten ? (bijvragen: tegenmaatregelen ?).
Code lijkt ongeveer hierop

        int main(int args, char **argc) {
        extern system,puts;	//Refers to system and output function. system(s) betekent voer
                                // command s uit, en puts(a) betekent print a uit.
        void *fn(char*) = (void *(char*)) &system; // fn is functiepointer en wijst initieel naar system
  	char[256] buf;
 
 	fn = (void *(char*)) &puts;
 	strcpy(buf,argc[1]);
 	fn(argc[2]);
 	exit(0);
 }

* (5p) Leg Role based access control uit. Wat zijn de voor- en nadelen tov de andere geziene modellen ?
Bijvraag: roles komen een beetje overeen met groepen. Zou je RBAC kunnen mappen op DAC ? Wat is het probleem ? -> antwoord: wie is de owner van een object = delicate kwestie; best root owner maken van alles, anders is het geen RBAC meer).

=== 17 januari 2011 (namiddag) ===

* Project bespreken (+ bijvragen over het hele webapplicaties-gedeelte) (5p)
* Security automaat geven voor DAC waar een object meerdere eigenaars kan hebben (5p)
* Leg indirect pointer overwrite uit: (5p)
*# Geef een voorbeeld-C-programma waar deze aanval kan gebruikt worden.
*# Leg elke stap van de aanval uit en teken telkens de geheugeninhoud schematisch.
*# Bespreek 2 tegenmaatregelen.
* Geef een beknopte definitie voor: (1p/begrip)
** Software vulnerability
** Defacement
** Non-repudiation
** Elevation of privilege
** Stack canary

=== 17 januari 2011 (voormiddag) ===

* Bespreking practicum/websecurity (5p)
** Wat vond je van Fortify?
** Jullie hebben vooral gefocused op destroy, is er niets anders dat een aanvaller zou willen?
** modsecurity vraagje
** iets van mashups
* Security automaat geven voor DAC waar een object van eigenaar kan wisselen (5p)
:DAC: beschrijf in het algemeen wat het doet,
:*schrijf code die een object aanmaakt
:*schrijf code die eigenaar van object zou wijzigen
:Bijvragen mondeling: iets geavanceerd: schrijf eentje die rechten toekent
* Wat is Heap-based-vulnerability? Hoe gebruikt een attacker dit om een aanval te plaatsen? Bespreek kort 2 tegenmaatregelen. (5p)
:Bijvragen:
:*stack unwinding
:*omzeilen van counter measures
* Geef een beknopte definitie voor: (1p/begrip)
**Defacement
**Phishing
**Data origin authentication
**XSS
**CAPTCHA

==2009-2010==
===11 januari (Ma informatica)===
#Project bespreken (5p)
#Geef een security automaat voor DAC waar een file meerdere eigenaars kan hebben. Geef enkele voor- en nadelen die je ziet t.o.v. standaard DAC. (De DAC security automaat is NIET gegeven)(5p)
#Leg indirect pointer overwrite uit a.d.h.v. een voorbeeld (bijvraag: waarom niet gewoon een buffer overflow uitvoeren?) (5 p)
#Geef een beknopte definitie voor: (1p/begrip)
* Software vulnerability
* Defacement
* Elevation of privilege
* Non-repudiation
* Stack canary

===20 januari===
#Mondelinge bespreking van het project. (5p) (Hier worden ook bijvragen gesteld die niet enkel over het project gaan maar over de volledige leerstof van web applicaties)
#Geef een security automaat voor DAC waar een object van eigenaar kan wisselen. Het object heeft wel op elk moment slechts ÃƒÂ©ÃƒÂ©n eigenaar. (5p)
#Leg basic stack buffer overflows uit aan de hand van een voorbeeld. (5p)
#Waarvoor dienen de enable_permission() en disable_permission() stack modifiers? Wat is het belang van deze modifiers? (5p)

Q6rFbf  <a href="http://aeiufgmidktg.com/">aeiufgmidktg</a>, [url=http://dvrjpjfeskko.com/]dvrjpjfeskko[/url], [link=http://azrclfzztwpd.com/]azrclfzztwpd[/link], http://hmgjhvxdmsek.com/

== 2005-2006 ==
=== 15 januari (burgies) ===
#Project bespreken
#Bespreek Kerberos (single sign-on, key distribution, ... heel de reutemeteut)
#Access control in Win2000: bespreek de algemene concepten en pas concreet toe.

=== maandag 23 januari ===
*project bespreken bij tine
*entity authentication: wat is dat? hoe dat men dat?
*beschrijf hoe men mobiele code uitvoert in platformen als Java en .net
*beschrijf de fout in volgend programma:
 int main(int argc, char *argv) {
   if( argc < 2 ) { exit(1); } // argc is het aantal command line argumenten + 1
   a( argv[1] ); // argv[1] is het eerste argument
 }
 
 void a( char* a ) {
   char b[200];
   strcpy( a, b ); // kopieer alles van a naar b tot het speciale "end of string" karakter wordt tegengekomen
 }

=== dinsdag 20 januari 2006 ===
*Bespreek de cryptografische primitieven en geef voor- en nadelen (en bespreek aan welke voorwaarden ze moeten voldoen (= known text only, .. die dinges).
*Hoe werkt toegangscontrole in Windows 2000/XP
*Bespreek certifivaatvalidatie in een PKI
*Project: overview geven / stackwalking (authorization) uitleggen / authentication uitleggen / andere security beveiligingen omschrijven en die Discretionnary forumowner uitleggen: NIET mogelijk via policy omdat die niet dynamisch gemaakt kan worden, moet dus extra in code gecontroleerd worden.

=== 30 januari 2006 (burgies) ===
#Mondelinge bespreking van het project. (5 punten)
#Bespreek de principiÃƒÂ«le werking van cryptografische protocols voor data protection, zowel voor het geval van synchrone (sessie-georiÃƒÂ«nteerde) communicatie als asynchrone (bericht-georiÃƒÂ«nteerde) communicatie (5 punten)
#Wat is het belang van de enable_permission() en disable_permission() stack walk modifiers? (5 punten)
#Wat is een "non-atomic check-and-use vulnerability"? Geef een voorbeeld. (5 punten)

== Voor 2006 ==
*Bespreking project (5pt)
*Geef een definitie van volgende begrippen: (1pt per begrip)
**collision-resistant
**opaque en transparent keys
**type sound
**single sign-on
**buffer overflow attack
** chosen-plaintext attack
** DAC
** Operation Modes (bij Block Ciphers)
** Key Authentication / Key Confirmation
*Geef een overzicht van de belangrijkste cryptografische primitieven, en zeg welke bescherming ze bieden. (5pt)
*Ontwikkel een veilig systeem om een garagedeuropener te laten werken met een poort zodat een vijand die alle radiosignalen opvangt niet de poort kan openen.  Analyseer de veiligheid van het door u ontwikkelde systeem (zwakheden e.d.) de poort kan niet terugsturen naar de zender (dus 1 richtingsverkeer)
*digi cash volledig uitleggen
*wat betekent het als een taal safe is, wat is type soundness in deze context, en wat is de invloed van deze twee begrippen op de veiligheid van software?
*in het kerberos protocol houden de clients de tickets bij als een soort "capabilities".  de servers houden geen informatie bij over hun clients. men zou het protocol zo kunnen aanpassen dat de servers een soort tokens bij houden, waarbij deze tokens de informatie bevatten over de identiteit van de client en de sessiesleutel die gebruikt wordt voor deze client.  beschrijf welke aanpassingen er nodig zijn aan het protocol om op deze alternatieve manier te werken, welke voordelen en nadelen je aan het nieuwe systeem ziet.
*Ontwerp een beveiliging voor een garagepoort met afstandsbediening. Het moet onmogelijk zijn om de radiogolven op te nemen en later opnieuw af te spelen. De afstandsbediening stuurt 1 digitale boodschap. Hoe ziet die er uit? Geef beveiligingsaspecten bij je ontwerp. Hoe gaat het algoritme in de garagepoort te werk?
*Leg Mandatory Acces Control uit en laat zien hoe het omgaat met Trojans.
*Bespreek Kerberos (5punten) zowel single sign-on als authenticatie als ..(nog iets)
**bijvraag: wat als je in stap 3 de authenticator {A,T}Ka weglaat?
***antwoord: meer aanvallen mogelijk op KDC
* Bespreek Access Control in Win2000 (5p)
**bijvraag: kan je tot meerdere groepen tegelijk horen (antwoord = JA)
*Wat is sandboxing? En waarvoor dient het? (5p)
*leg buffer overflow uit
**bijvraag: hoe kunt ge als ge een gecompileerd C programma koopt en ge wilt niet testen op bufferoverflow toch zorgen dat ge niet met een bufferoverflow wordt aangevallen ?
**antwoord:zorgen dat uw OS onderscheid maakt tussen code en data in het geheugen data kan nooit worden uitgevoerd (ook niet als ge daar code overschrijft)
*leg stack walking uit voor mobiele code
*wat is MAC, + Trojaanse paard en verband tussen beide (5punten)
*geef commentaar op "SSL is waardeloos zonder deftige PKI" (5 punten)
*wat is het belang van enable_permission(0 en disable_permission() bij stackwalking
*Wat is een "man-in-the-middle" aanval?  Geef een concreet voorbeeld.
*Geef een overzicht van hoe de Java Cryptografie Architectuur en Extensies werken.
* Geef een overzicht van mogelijke oorzaken van software beveiligings-zwakheden (vulnerabilities).
*Wat is een "Cryptographic Service Provider (CSP)"? Hoe werken CSP's en wat zijn de voordelen ervan?
*Bytecode verificatie van mobiele code en verificatie van handtekeningen op mobiele code zijn twee mechanismen die de JVM gebruikt om te beschermen tegen "kwaadaardige" code. Bespreek in hoeverre het nuttig is om beide mechanismen te combineren. Of met andere woorden: is het al dan niet nog zinvol om bytecode verificatie te doen van een klasse waarvan de handtekening al correct geverifieerd is?
*Bespreek het systeemmodel voor een multi-user besturingssysteem
*Bespreek verificatie van een certificaat in een PKI
*Mac's en Digitale handtekeningen zorgen beiden voor integrity controle en origin authentication, definieer beiden, geef verschillen en gelijkenissen, voor en nadelen. (5ptn)
*Geef een threatanalyse van een p2p file sharing systeem, bespreek de architectuur en bespreek de threats die je ziet. (gelijkaarding aan geziene emailsysteem) (5ptn) toch wil ie hier graag horen wat de assets zijn van het systeem en dan via het STRIDE model (laatste slides) zo de threats gaan identificeren...

[[Categorie:mi]]