Inhoud leereenheid 3 Validatie van invoer en uitvoer Introductie 31 Leerkern 32 1 Invoervalidatie 32 2 Invoer- en uitvoervalidatie voor webapplicaties 35 Terugkoppeling 39 30
Leereenheid 3 Validatie van invoer en uitvoer I N T R O D U C T I E In deze leereenheid besteden we aandacht aan een aantal beruchte vulnerabilities uit het pernicious kingdom Input validation and representation. Deze vulnerabilities behoren tot de meest voorkomende en staan steevast bovenaan in de ranglijsten van vulnerabilities. We besteden ook aandacht aan technieken om deze vulnerabilities af te wenden en valkuilen die vermeden moeten worden. In het eerste deel van deze leereenheid kijken we naar invoervalidatie. In het tweede deel kijken naar webapplicaties, waarbij naast invoervalidatie ook uitvoervalidatie een rol speelt. LEERDOELEN Na het bestuderen van deze leereenheid wordt verwacht dat u kunt uitleggen dat alle invoer, van alle mogelijke bronnen, gevalideerd moet worden alvorens de ingevoerde gegevens gebruikt mogen worden geschikte technieken (indirect selection, whitelisting, reguliere expressies, invoerlengte controleren, minimum en maximum waarde van getallen controleren, geparameteriseerde invoer) voor invoervalidatie kunt toelichten en toepassen valkuilen kunt herkennen bij invoervalidatie, zoals het gebruik van blacklisting, het ondermijnen van security door gebruiksvriendelijkheid, het repareren van ingevoerde gegevens en het tonen van gedetailleerde foutmeldingen de security-concepten trust boundaries en security-enhanced API kunt toelichten het gevaar kunt toelichten van invoer waarin controlestructuren, data en metacharacters zijn toegestaan de vulnerabilities SQL injection, path manipulation, command injection en log forging kunt toelichten de vulnerabilities cross-site scripting, HTTP response splitting, open redirects en cross-site request forgery in webapplicaties kunt toelichten vulnerabilities rondom HTTP sessiemanagement kunt toelichten. Studeeraanwijzing In deze leereenheid bestudeert u twee hoofdstukken uit het tekstboek Secure programming with static analysis van Brian Chess en Jacob West. De theorie in deze hoofdstukken wordt met talloze voorbeelden toegelicht. Het is illustratief en leerzaam om deze voorbeelden te bekijken, maar ze behoren niet expliciet tot de tentamenstof. Na bestudering van deze leereenheid moet u in fragmenten programmacode de behandelde vulnerabilities kunnen aanwijzen en kunnen toelichten hoe ze opgelost kunnen worden. De studielast van deze leereenheid bedraagt circa 8 uur. 31
Open Universiteit Software security L E E R K E R N 1 Invoervalidatie Studeeraanwijzing Pagina 122-123 Pagina 124 Pagina 131-132 Pagina 135 Weblinks Bestudeer hoofdstuk 5 Handling Input (pagina 117 tot en met 173) uit het tekstboek Secure programming with static analysis van Brian Chess en Jacob West. Het voorbeeld in de sectie Configuration Files heeft betrekking op de invoer van een reguliere expressie. De reguliere expressie bestaat uit een concatenatie van maximaal tien capturing groups. Een capturing group is een subexpressie tussen haakjes, bijvoorbeeld (abc). In Example 5.1 is te zien dat de capturing groups worden opgeslagen in array regmatch[10]. Deze array bestaat uit 10 elementen: regmatch[0] tot en met regmatch[9]. Het aantal capturing groups wordt opgeslagen in de variabele re_nsub. Het is mogelijk dat deze variabele, vermeerderd met 1, een waarde bevat die groter dan 10 is. De variabele regexp verwijst dan naar een array met meer dan 10 elementen, maar in het geheugen is slechts ruimte voor 10 elementen gealloceerd. De tekst onderaan pagina 122 geeft aan dat een reguliere expressie met 10 of meer capturing groups een buffer overflow veroorzaakt. Dat is incorrect: de buffer overflow treedt op bij 11 of meer capturing groups. In Example 5.2 wordt deze vulnerability opgelost door de constante AP_MAX_REG_MATCH te introduceren die de grootte van array regmatch aangeeft. Deze constante wordt in plaats van variabele re_nsub gebruikt om de grootte van de array aan te geven. In Example 5.3 wordt op regel 3 getest of de string args[i] begint met de tekst --delimiter=. Als dat zo is, wordt op regel 4 aan de string delimiter de substring van args[i] toegekend beginnende vanaf element 12, wat overeenkomt met de tekst die achter --delimiter= staat. De bedoeling is dat delimiter een enkel karakter bevat, echter elke string met willekeurige lengte wordt geaccepteerd. In de sidebar Static Analysis: Enforce Trust Boundaries komt het begrip taint propagation ter sprake. Tainted data zijn ingevoerde gegevens die mogelijk gevaarlijk kunnen zijn. Taint propagation analyse detecteert de tainted dataflow van bron (invoer van gegevens) naar bestemming (gebruik van gegevens in gevaarlijke operatie). Taint propagation analyse wordt toegepast in statische analyse van programmacode. In leereenheid 10 komt dit uitgebreider aan de orde. Reguliere expressies vormen een krachtig hulpmiddel om invoer te valideren. In Example 5.10 bevat de string regex een reguliere expressie. De escape sequence \\ in een Javastring duidt het backslash-karakter ( \ ) aan. De string regex representeert derhalve de reguliere expressie ^[0-9\-\. ]+$. Hierin duidt ^ het begin van een regel aan, $ het einde van een regel, escape sequence \- het karakter - en escape sequence \. het karakter.. Ontdaan van alle franje luidt de reguliere expressie dus [0-9-. ]+. Deze expressie duidt een reeks aan die bestaat uit één of meer tekens, waarbij elke teken een getal is (0-9), een dash ( - ), een punt (. ) of een spatie ( ). 32
Leereenheid 3 Validatie van invoer en uitvoer Het Javapackage java.util.regex bevat drie klassen (Pattern, Matcher en PatternSyntaxException) waarmee gecontroleerd kan worden of een zekere reeks karakters voldoet aan een reguliere expressie. Een object van de klasse Pattern is een gecompileerde representatie van een reguliere expressie. Een Pattern object wordt geconstrueerd door de methode Pattern.compile aan te roepen met een reguliere expressie als argument. Een Matcher object interpreteert de reguliere expressie en matcht de expressie met een input string. Een Matcher object wordt geconstrueerd door de methode Pattern.matcher. Een voorbeeld: Pattern p = Pattern.compile("a*b"); Matcher m = p.matcher("aaaaab"); boolean b = m.matches(); De string aaaaab voldoet aan de reguliere expressie a*b. De variabele b heeft daarom de waarde true. Deze reeks opdrachten kan ook verkort geschreven worden als boolean b = Pattern.matches("a*b", "aaaaab"); Pagina 136 In Example 5.11 geeft de string sep de reguliere expressie \s*[.-]?\s* aan. De escape sequence \s duidt een whitespace karakter aan (zoals spatie of tab). De quantifier * duidt nul of meer aan, en? nul of één. De reguliere expressie representeert dus een reeks tekens die bestaat uit nul of meer whitespace karakters, eventueel gevolgd door. of -, en afgesloten door nul of meer whitespace karakters. In Example 5.11 wordt deze reeks gebruikt om de groepen getallen in een telefoonnummer van elkaar te scheiden. OPGAVE 3.1 Schrijf een Java-programma dat een wachtwoord inleest en controleert met behulp van reguliere expressies of dit wachtwoord uit minimaal 8 tekens bestaat waaronder minstens één hoofdletter, minstens één kleine letter, minstens één cijfer en minstens één van de volgende nietalfanumerieke tekens:!, @, #, $, %, ^, &, *, (, ) en?. Maak gebruik van package java.util.regex en eventueel de Javaklasse RegexTestHarness.java (zie link op Studienet). Pagina 140 Pagina 146 In URL encoding worden gereserveerde karakters weergegeven in de percent encoding. Zo wordt het karakter : gerepresenteerd als %3A, het karakter \ als %5C en het karakter % als %25. Een string wordt in C gerepresenteerd als een array van characters waarbij het laatste character een null character ('\0') moet zijn. Bij geheugenallocatie moet hiermee rekening worden gehouden. De programmacode char a[3] = abc ; is daarom incorrect en dient char a[4] = abc ; te zijn. De functie readlink heeft drie parameters: char *path, char *buf en size_t bufsize. De pointer path wijst naar een string die het pad naar een symbolische link bevat. De functie readlink plaatst de naam van het bestand waarnaar de symbolische link wijst, in de variabele buf. De variabele bufsize geeft de grootte van buf aan. De terugkeerwaarde geeft het aantal characters dat in buf is geplaatst. Bij fouten is de terugkeerwaarde -1. 33
Open Universiteit Software security Pagina 157-160 Weblinks In C# wordt een OverflowException gegenereerd als een integer overflow optreedt. Java heeft daarentegen geen standaard ingebouwde verdediging tegen integer overflows. Alleen de integer deeloperator (/) en integer modulo-operatie (%) kunnen een ArithmeticException genereren. Verder kent Java alleen signed integer types, behalve dan het type char dat wordt gerepresenteerd als een 16-bit unsigned waarde. Op de cursussite in Studienet vindt u achtergrondinformatie over de getalrepresentatie in Java. OPGAVE 3.2 Een programma bevat de volgende programmacode, waarin alle variabelen van het type integer zijn: size = (elements * sizeof(elements)) + sizeof(header); Er treedt een integer overflow op als size groter is dan MAX_INT. Geef een stukje programmacode dat het optreden van een integer overflow tijdens run-time voorkomt. Pagina 163-164 Weblinks Pagina 166 Weblinks JDBC (Java Database Connectivity) is een standaard Java-interface om vanuit Java te communiceren met een relationele database. Deze interface heeft de subinterfaces PreparedStatement en CallableStatement waarmee SQL injection voorkomen kan worden. In Example 5.29 wordt een PreparedStatement object toegepast. De regel PreparedStatement stmt = conn.preparestatement(query); stuurt de SQL-query SELECT * FROM items WHERE owner =? AND itemname =? naar het DBMS waar de query wordt gecompileerd. Het PreparedStatement object bevat dus een gecompileerde SQL-query. De vraagtekens in deze query dienen als placeholders (bind parameters). In de opdrachten stmt.setstring(1, username); en stmt.setstring(2, itemname); worden vervolgens waarden aan deze parameters toegekend. Met de opdracht ResultSet rs = stmt.executequery(); wordt de query ten slotte door het DBMS uitgevoerd. Met een geparameteriseerde SQL-query wordt het onderscheid tussen SQL-opdrachten en data expliciet gemaakt. De bind parameters kunnen alleen data bevatten, waarmee SQL-injectie voorkomen kan worden. Correct gebruik van geparameteriseerde queries is daarbij natuurlijk wel een vereiste. Example 5.30 toont hoe het niet moet. Een voorbeeld van een stored procedure in Oracle's PL/SQL is als volgt: CREATE PROCEDURE login (name VARCHAR(100), pwd VARCHAR(100))AS DECLARE @sql nvarchar(4000) SELECT @sql =' SELECT * FROM Account WHERE username=' + @name + 'AND password=' + @pwd EXEC (@sql) Deze stored procedure kan vanuit Java als volgt aangeroepen worden: CallableStatement proc = connection.preparecall("{call login(?,?)"); proc.setstring(1, username); proc.setstring(2, password); Hier is sprake van een geparameteriseerde call. 34
Leereenheid 3 Validatie van invoer en uitvoer OPGAVE 3.3 Bekijk de onderstaande Javacode waarin een stored procedure in Oracle PL/SQL wordt aangeroepen om de postcode van een plaats op te vragen. String name = request.getparameter("name"); String sql = "GetPostalCode('" + name + "');"; CallableStatement cs = conn.preparecall(sql); cs.executeupdate(); String result = cs.getstring(1); cs.close(); a Wat is de vulnerability in deze code? b Geef een voorbeeld van hoe deze vulnerability misbruikt kan worden. c Repareer de code. Pagina 168 Example 5.33 kwam ook in leereenheid 2 (opgave 2.1) aan de orde. 2 Invoer- en uitvoervalidatie voor webapplicaties Studeeraanwijzing Pagina 301 Pagina 303 Pagina 304-308 Bestudeer sectie 9.1 Input and Output Validation for the Web, sectie 9.2 HTTP Considerations en sectie 9.3 Maintaining Session State (pagina 297 tot en met 336) uit het tekstboek Secure programming with static analysis van Brian Chess en Jacob West. In sectie 9.2 (pagina 319-321) gaan we verder in op de verschillen tussen POST en GET. Op de laatste regel wordt gesteld dat cross-site scripting in 2006 de meest verbreide software vulnerability was volgens CWE. De ranglijsten van software vulnerabilities worden regelmatig bijgesteld (zie leereenheid 2). Cross-site scripting was en is een van de meest verbreide vulnerabilities in webapplicaties. Cross-site scripting (XSS) is een vulnerability ten gevolge van gebrekkige validatie van invoer en uitvoer door een webserver. In het tekstboek komen twee vormen van XSS aan de orde: reflected en stored XSS. Reflected XSS wordt ook wel aangeduid als nonpersistent XSS of type 1 XSS; stored XSS wordt ook wel aangeduid als persistent XSS of type 2 XSS. Bij reflected XSS is er altijd sprake van een of andere vorm van social engineering. Het slachtoffer wordt verleid om op een link te klikken, bijvoorbeeld in een phishing e-mail of op een malafide website. De link kan bijvoorbeeld een query parameter met JavaScript-code bevatten. Als de webserver de JavaScript-code terugzendt naar de browser van het slachtoffer, wordt de code daar uitgevoerd. De code kan bijvoorbeeld het cookie van het slachtoffer naar de aanvaller doorsturen. Een ander voorbeeld is dat de code een webformulier aan het slachtoffer toont waarin deze wordt verzocht om informatie in te vullen, die vervolgens naar de aanvaller wordt doorgestuurd. Dit wordt in Figure 9.4 geschetst. Bij stored XSS is social engineering niet nodig. De aanvaller injecteert code in de dynamische content van webpagina s die op de webserver wordt opgeslagen (als verzuimd wordt om deze invoer te valideren). Als een volgende bezoeker deze webpagina s bezoekt, wordt de code naar de browser van deze bezoeker gestuurd (als verzuimd wordt om deze uitvoer te valideren) en wordt de code door de browser uitgevoerd. 35
Open Universiteit Software security De oudste vorm van stored XSS trad op bij websites die een gastenboek aanbieden waarin bezoekers een bericht kunnen achterlaten. Een kwaadwillende gebruiker kan aan dit bericht bijvoorbeeld JavaScriptopdrachten toevoegen, die door de browsers van volgende bezoekers wordt uitgevoerd. Dit wordt in Figure 9.5 geschetst. XSS is in de eerste plaats een vulnerability in de webserver, aangezien de webserver malicious content naar de client stuurt. De tussenkomst van de webserver is echter niet altijd vereist, bijvoorbeeld als de code reeds aanwezig is in de browsercache van de client. Een derde vorm van XSS staat bekend als DOM-based XSS, ook wel local XSS of type 0 XSS genoemd. Ook daarbij is geen tussenkomst van de webserver vereist. De aanvaller maakt daarbij gebruik van run-time embedding in webpagina s om kwaadaardige code in de DOM (Document Object Model) te plaatsen. OPGAVE 3.4 Op Studienet vindt u links naar twee animaties waarin voorbeelden van stored XSS worden gegeven. Bekijk deze animaties. Van welke vulnerability maakt Mel gebruik? Pagina 309-312 Pagina 312-314 De sidebar geeft een aardige illustratie van de werkwijze van een hacker. Het bestaat veelal uit trial-and-error en het zoeken naar creatieve oplossingen om beveiligingsmechanismen te omzeilen. Zoals toegelicht, lag het gebruik van blacklisting aan de basis waardoor XSS in deze webapplicatie mogelijk is. XSS kan voorkomen worden door invoer- en uitvoervalidatie, bij voorkeur door gebruik te maken van whitelisting en output encoding. Verder is toepassing van het principle of least privilege op zijn plaats, zoals het uitschakelen van scripting talen, toegang tot cookies inperken en gevoelige gegevens niet in cookies opslaan. Op pagina 313 wordt JSP als voorbeeld gegeven. JSP (JavaServer Pages) is gebaseerd op Java en bedoeld voor het server side ontwikkelen van dynamische websites. JSP ondersteunt scripting elementen en tags die vergelijkbaar zijn met HTML en XML markup. De JSP Standard Tag Library (JSTL) implementeert een aantal basisfuncties zoals data formatting. Output encoding, ook wel escaping genoemd, is een techniek die ervoor zorgt dat karakters worden behandeld als data in plaats van metakarakters die deel uitmaken van programmacode. Er zijn talloze manieren voor output encoding in diverse programmeertalen en API s; sommige maken gebruik van escape sequences, andere hebben een geavanceerdere syntax. Welke het beste toegepast kan worden, hangt af van hoe de data gebruikt wordt, zoals in de body van een HTML document, als HTML attribute, in JavaScript, CSS, XML, een URL of een SQL-query. In Example 9.5 wordt HTML entity encoding toegepast, waarbij sommige karakters vervangen worden door hun HTML-equivalent. Bijvoorbeeld het karakter < wordt vervangen door <. In Example 9.6 wordt URL encoding toegepast, waarbij sommige karakters vervangen worden door een % teken gevolgd door de ASCII-waarde in hexadecimale notatie. 36
Leereenheid 3 Validatie van invoer en uitvoer Pagina 314 Pagina 327 Bij XSS is de kwaadaardige code ingebed in de body van de HTML-pagina die naar de client wordt verstuurd. Bij HTTP response splitting wordt de kwaadaardige code ingebed in de HTTP-header van de webpagina die naar de client wordt verstuurd. Cross-site request forgery wordt gewoonlijk afgekort tot CSRF of XSRF. OPGAVE 3.5 Op Studienet vindt u een link naar een animatie waarin een voorbeeld van CSRF wordt gegeven. Bekijk deze animatie. Vergelijk deze aanval met de car auction XSS animatie uit opgave 3.4. Wat is het onderscheid tussen CSRF en XSS? Pagina 328-336 Tot slot Weblinks Omdat HTTP toestandloos is, dient een webapplicatie zelf sessiemanagement te implementeren. Aan het begin van een sessie zal de webserver een session identifier toekennen en deze aan de client meedelen. De client dient deze session identifier in volgende requests mee te sturen, zodat de server deze requests aan de sessie kan koppelen. De session identifier wordt gewoonlijk via een cookie HTTP header, een URL query string of een hidden form field tussen client en server uitgewisseld. De session identifier dient complex en willekeurig genoeg zijn zodat deze niet door een buitenstaander geraden kan worden. Tevens dient de session identifier versleuteld verzonden te worden, bij voorkeur via HTTPS, zodat een buitenstaander deze niet kan afluisteren. Vanuit oogpunt van security dient een sessie ook netjes afgesloten te worden, bijvoorbeeld door een logout-functie. Een gevaar daarbij is dat de gebruiker de sessie verlaat, maar verzuimt om de logout-functie te gebruiken waardoor de sessie open blijft. Het is daarom aan te raden om sessies slechts een beperkte levensduur te geven (gewoonlijk 20 tot 30 minuten), waarna de server de sessie beëindigt. Een vulnerability is verder een incorrecte logout-functie die de sessie niet of slechts ten dele beëindigt. Een voorbeeld is de terugknop waarmee de gebruiker na uitloggen terug kan keren naar de sessie zonder opnieuw te hoeven inloggen. Als afsluiting van deze leereenheid vatten we een aantal technieken samen voor validatie van invoer en uitvoer in webapplicties, zoals weergegeven in de OWASP Secure Coding Practices Quick Reference Guide. Input Validation: Conduct all data validation on a trusted system (e.g., the server) Identify all data sources and classify them into trusted and untrusted; validate all data from untrusted sources (e.g., databases, file streams, etcetera) There should be a centralized input validation routine for the application Specify proper character sets, such as UTF-8, for all sources of input Encode data to a common character set before validating (canonicalize) All validation failures should result in input rejection Determine if the system supports UTF-8 extended character sets and if so, validate after UTF-8 decoding is completed 37
Open Universiteit Software security Validate all client provided data before processing, including all parameters, URLs and HTTP header content (e.g., cookie names and values); be sure to include automated post backs from JavaScript, Flash or other embedded code Verify that header values in both requests and responses contain only ASCII characters Validate data from redirects (an attacker may submit malicious content directly to the target of the redirect, thus circumventing application logic and any validation performed before the redirect) Validate for expected data types Validate data range Validate data length Validate all input against a white list of allowed characters, whenever possible If any potentially hazardous characters must be allowed as input, be sure that you implement additional controls like output encoding, secure task-specific APIs and accounting for the utilization of that data throughout the application; examples of common hazardous characters include: < > " ' % ( ) & + \ \' \" If your standard validation routine cannot address the following inputs, then they should be checked discretely: check for null bytes (%00), check for new line characters (%0d, %0a, \r, \n), check for dot-dot-slash (../ or..\) path alterations characters; in cases where UTF-8 extended character set encoding is supported, address alternate representation like: %c0%ae%c0%ae/ (utilize canonicalization to address double encoding or other forms of obfuscation attacks). Output Encoding: Conduct all encoding on a trusted system (e.g., the server) Utilize a standard, tested routine for each type of outbound encoding Contextually output encode all data returned to the client that originated outside the application's trust boundary; HTML entity encoding is one example, but does not work in all cases Encode all characters unless they are known to be safe for the intended interpreter Contextually sanitize all output of untrusted data to queries for SQL, XML, and LDAP Sanitize all output of untrusted data to operating system commands. 38
Leereenheid 3 Validatie van invoer en uitvoer T E R U G K O P P E L I N G 3.1 Een reguliere expressie zou er als volgt uit kunnen zien: [ [A-Z]+ [a-z]+ [0-9]+ [!@#$%^&*()?]+ ]{8,. Deze expressie is opgebouwd uit geneste karakterklassen. Helaas ondersteunt package java.util.regex geen nesting. Een alternatief is daarom om vijf aparte reguliere expressies te nemen, en te controleren of het ingevoerde wachtwoord aan elk van deze vijf reguliere expressies voldoet. Het Java-programma kan er bijvoorbeeld als volgt uitzien: import java.io.*; import java.util.regex.pattern; import java.util.regex.matcher; public class RegexTestHarness { public static void main(string[] args) throws IOException { InputStreamReader c = new InputStreamReader(System.in); BufferedReader in = new BufferedReader(c); String[] regex = new String[5]; int i; regex[0] = "[A-Z]+"; regex[1] = "[a-z]+"; regex[2] = "[0-9]+"; regex[3] = "[!@#$%^&*()?]+"; regex[4] = ".{8,"; while (true) { System.out.print("Password: "); String password = in.readline(); for (i=0; i<5; i++) { Pattern pattern = Pattern.compile(regex[i]); Matcher matcher = pattern.matcher(password); if (!matcher.find()) System.out.println("Password does not match regular expression "+regex[i]); 39
Open Universiteit Software security Een elegantere oplossing is om gebruik te maken van een reguliere expressie bestaande uit non-capturing groups met een lookahead operatie: import java.util.regex.pattern; import java.util.regex.matcher; import javax.swing.joptionpane; public class RegexTestHarness { public static void main(string[] args) { String regexpr ="^(?=.*[0-9])"+"(?=.*[a-z])"+ "(?=.*[A-Z])"+"(?=.*[!@#$%^&*()?])"+".{8,$"; Pattern pattern = Pattern.compile(regexpr); while (true) { String input = JOptionPane.showInputDialog("password", null); Matcher matcher = pattern.matcher(input); if (matcher.matches()) { System.out.println("Password is ok."); else { System.out.println("Password is not ok."); 3.2 Er moet gelden dat (elements * sizeof(elements)) + sizeof(header) MAX_INT. Deze expressie kunnen we herschrijven als MAX_INT - (elements * sizeof(elements)) - sizeof(header) 0. In deze expressie kan nog steeds een integer overflow optreden als elements * sizeof(elements) > MAX_INT. We herschrijven de expressie daarom tot (MAX_INT - sizeof(header)) / sizeof(elements) elements. In deze expressie treedt geen integer overflow op, aangezien er geldt dat sizeof(header), sizeof(elements) en elements groter dan nul en kleiner dan MAX_INT zijn. We kunnen het optreden van een integer overflow daarom tijdens runtime voorkomen met de volgende code: if ((MAX_INT - sizeof(header)) / sizeof(elements) >= elements) size = (elements * sizeof(elements)) + sizeof(header); else // genereer exceptie of foutmelding, // of repareer bv. met size = MAX_INT; 3.3 a De vulnerability wordt veroorzaakt doordat de SQL-query wordt samengesteld uit een string concatenatie. Er wordt verzuimd om gebruik te maken van geparameteriseerde invoer. Deze vulnerability is vergelijkbaar met Example 5.30. 40
Leereenheid 3 Validatie van invoer en uitvoer b De ontwikkelaar had in gedachte dat de gebruiker een plaatsnaam invoert. Een voorbeeld is de plaatsnaam Boston. De call is dan GetPostalCode( Boston );. Een aanvaller kan echter bijvoorbeeld een willekeurige opdracht toevoegen zoals '); delete * from users; commit; --. De call luidt dan: GetPostalCode(''); delete * from users; commit; c De gerepareerde code luidt als volgt: String name = request.getparameter("name"); CallableStatement cs = conn.preparecall("getpostalcode(?);"); cs.setstring(1, name); cs.executeupdate(); String result = cs.getstring(1); cs.close(); 3.4 Mel observeert in beide animaties dat de webapplicatie toestaat om code, zoals HTML en JavaScript, in het bericht op te nemen. Op zich is dat niet zorgwekkend. De situatie wordt echter gevaarlijk als de webapplicatie geen invoervalidatie uitvoert om deze code uit het bericht te verwijderen. Het gaat echt mis als de webapplicatie naast invoer- ook uitvoervalidatie verzuimt. Het bericht met kwaadaardige code komt dan terecht bij een andere gebruiker waar de code door diens browser wordt uitgevoerd. De vulnerability is dus gebrek aan validatie van invoer en/of uitvoer. 3.5 Het essentiële onderscheid is dat XSS misbruik maakt van het vertrouwen dat een client in een website of webapplicatie heeft, terwijl CSRF misbruik maakt van het vertrouwen dat de website of webapplicatie in de client heeft. In de car auction XSS-animatie vertrouwt Alice erop dat de getoonde webpagina s legitiem zijn. Een van de webpagina s bevat echter een script waarmee haar cookie naar de webserver van Mel wordt verstuurd. Vervolgens zou Mel dit cookie kunnen gebruiken om spoofing te plegen en zich als Alice voor te doen, maar strikt genomen behoort dat vervolg van de aanval niet meer tot XSS. De CSRF-animatie schetst een vergelijkbaar situatie, waarin Alice erop vertrouwt dat de getoonde webpagina s legitiem zijn. Een van de webpagina s ontlokt echter een request naar de webserver waarin ze een bod uitbrengt. De webapplicatie gaat er van uit dat dit bod door Alice gedaan is, aangezien het bericht afkomstig is van Alice zelf. In feite is het eerste deel van de aanval, waarin Mel de code injecteert in de webserver, een vorm van stored XSS. Het tweede deel van de aanval, waarin Alice onwetend het bod plaatst, is de daadwerkelijke CSRF. 41