OWASP Top 10 - Benoist Top 10 Emmanuel Benoist ... Write Hardening guideline for your application Con guring all security mechanisms ... store using a public key, only backend program

Hacking Web SitesOWASP Top 10

Emmanuel BenoistSpring Term 2018

Berner Fachhochschule | Haute cole spcialise bernoise | Berne University of Applied Sciences 1

Web Security: Overview of othersecurity risks� OWASP Top 10

� Top 10 Web Security Risks

� A5 - Security Misconfiguration

� A6 - Sensitive Data ExposureExamples of attacksRecommendations

� A7 - Insufficient Attack Protection

� A9 - Using components with known vulnerabilities

� A10 - Underprotected APIs

� Security Risks vs. Attacks

� Conclusion

� References


OWASP Top 10


OWASP Top 10

10 most critical security risks for web applications

GoalRaise awareness of people about application security

Based on real examples8 datasets from 7 firms specialized in application security500’000 vulnerabilities, thousands of applicaitonsSorted on the prevalence data in combination with risks(exploitability, detectability and impact estimation)


What are application security risks?

Attackers can use many different paths to do harm


Top 10 Web Security Risks


OWASP Top 10

Presents the 10 most critical web application securityrisks

Produced by the Open Web Application Security Project(OWASP)Available on line www.owasp.org

Updated in 2017

Not Exhaustivehundreds of other issues occure in Web SecurityBut it is foccused on the most critical ones


OWASP Top 10Version 2017

A1:2017 - Injection Seen

A2:2017 - Broken Authentication Seen

A3:2017 - Sensitive Data Exposure Seen

A4:2017 - XML External Entities (XXE)

A5:2017 - Broken Access ControlSeen

A6:2017 - Security Misconfiguration

A7:2017 - Cross-Site Scripting (XSS) Seen

A8:2017 - Insecure Deserialization

A9:2017 - Using components with known vulnerabilities

A10:2017 - Insufficient Logging and Monitoring


A5 - Security Misconfiguration


A5 - Security MisconfigurationProcess for keeping software up-to-date

OSWeb /App ServerDBMS

Is everything unnecessary disabled?ports, services, pages, accounts, priviledges

Are default account passwords changed or disabledBefore the first connection to the net

Is your error handling set to prevent informativemessages

Stack tracesSQL errors

Are the security settings in your developmentframeworks understood and configured properly

Struts, JSF, Spring, ASP.NETLibraries

Repeatable process is required


A5 - Security Misconfiguration(Cont.)

Application relies on a framework (JSF, Struts, Spring)A flow is found in the frameworkAn update is releasedYou don’t install the updateAttackers will used the known vulnerability

The application has a default admin page with defaultpwd

You forget to remove the tool and to change the pwdAttack logs in using default value


A5 - Security Misconfiguration(Cont.)

Directory listing is not disabledAttacker can browse directories and find any file.He downloads Java .class files and uncompile them, thenknows your code.

Access to “configuration” files not properly restrictedRead the database configuration in a “password.inc” file inPHP


How to determine if you arevulnerable

If you did nothing: you are vulnerableAlmost no application is secure “out of the box”

Secure configuration of the server should be documentedRegularly updatedYou should check if the actual configuration is still conformregularly

Scanner can check for known vulnerabilities

Nessus or Nikito for instanceYou should run them on a regular basis


ProtectionWrite Hardening guideline for your application

Configuring all security mechanismsTurning off all unused servicesSetting up roles, permissions, and accounts, including disablingall default accounts or changing their passwordsLogging and alerts

Use an automatic configuration toolMust maintain the configuration on all your servers

The maintenance process should include:Monitoring the latest security vulnerabilities publishedApplying the latest security patchesUpdating the security configuration guidelineRegular vulnerability scanning from both internal and externalperspectivesRegular internal reviews of the server’s security configurationas compared to your configuration guideRegular status reports to upper management documentingoverall security posture


A6 - Sensitive Data Exposure


A6 - Sensitive Data ExposureGive access to unprotected data

Sensitive data should appropriately be protectedEncryption and hashing of sensitive data is a MUST

Crypto should be taken seriouselyNo encryption (including no TLS) is a big riskEncryption needs to store data securely

Example1: Credit Card numbers stored in a Data BaseStored encrypted automatically by the DataBaseCan be retreived by SQL onlyVulnerable to SQL injectionSolution: store using a public key, only backend programknows the private key to retreive information

Example 2: No SSL/TLS encryption after the loginCookies of the user can be stollen, and reused for sessionhijakingSolution: Use TLS for all your interactions with authenticatedusers. And force cookies just to be sent to https site.


A6 - Sensitive Data Exposure (Cont.)

Example 3: Password hashed without a saltHashed password data can be stollen (sql injection or fileupload flaw)Hashes can be compared with precalculated hashes (rainbowtables)

ProtectionEncrypt all sentitive data anytime (even inside your internalnetwork)Discard sensitive data ASAPUse strong standard algorithms and keysDisable autocomplete for sensitive data and caching of pagescontaining sensitive data


Exploitability

Attackers typically don’t break crypto directlyBreak something elseSteal keysman-in-the-middle

Steal clear text dataon the serverin transitfrom user’s browser


Hard to exploit

Simple: no encryption at allthe most common flaw

When crypto is employedweak key generationweak key managementweak algorithm usage

Difficult to detect server side flawslimited accesshard to exploit


Impact is Severe

Compomises sensitive dataHealth recordscredentialspersonal datacredit cards. . .

Impact on your businessValue of data for competitorsReputationCompliance


Examples of attacks


NSA vs. Google

Wikileaks showed that NSA was spying on google mailTons of mails were readableNSA listened to communication between datacentersCommunication was cleartext

Google strengthtened its systemsHTTPS for any client to gmailencryption of data between servers


Heartbleed

Disovered in 2014Bug in the library Open SSLImplementation of Heartbeat by a PhD studentHeartbeat : extension for TLS (Transport Layer Security)

PrincipleEach heartbeat exposed up to 64kB of memory

VictimsCanada Revenue Agency : theft of 900 taxpayers SocialInsurance Numbersin UK, Mumsnet had accounts hijacked (including CEO’s one)


Scenario: encrypted database

A Database is stored encryptedAutomatic encryption is doneData stored on the disk are unreadableBut SQL injection can read Credit Card Numbers

SolutionEncrypt data with a public keyCards can only be read from back-endusing private keyData are “write only”


Scenario: HTTP vs HTTPS

A site has HTTP pagesLogin occures in HTTPS pagesRest of pages are HTTPSAnother part of site is HTTP

If cookie is not “secure”SessionID is sent also for HTTP pages / resources (images,css, . . . )Can be spyed by third partyCan be used for inpersonating the victim


Are you exposed?

First define which data are sensitiveHealth dataCredit Card informationpersonal informationCredentials (passwords, keys, . . . )

Are they stored clear text?Including Backup

Are they transmitted clear text?On the internetInside the internal network


Are you exposed? (Cont)

Do you use weak or old crypto?Some algorithms are proven weak (MD5 for instance)Configuration is crutialNo self made crypto library : details are important

Do you use the browser correctly?security directives or headers missing?


Recommendations


Store sensitive data that you need

Credit Card numberMany shops use third party payment providersNo need to store Credit Card numbersReceives a transaction number certified by the bank

ExamplesZalando uses “Verified by Visa” or “MasterCard secure code”The bank verifies the validity of the card (using TAN forinstance)


Only use strong cryptographicalgorithms

Use only approved public algorithmsAES for symetric encryption,RSA for public key crypto,SHA-256 or better for hash functions

Don’t use weak algorithmsMD5SHA1

Classification changes with the timeFor more details: CAPV program validates crypto algorithmshttp://csrc.nist.gov/groups/STM/cavp/index.html

Configuration is also importantChoice of saltsIntegrity with MAC (HMAC-SHA256 or HMAC-SAH512)


Ensure that random numbers arecryptographically strong

Random generators are used forrandom numbersrandom file namesrandom userID’s or sessionID’srandom strings

Should be generated in a cryptographically strongfashion

No one should guessSeeded with sufficient entropy

Bad exampleSeed = current time in milliseconds or microsecondsVery easy to know (or brute force)


Use only widely acceptedimplementations of crypto algorithms

Do not implement an existing algo on your ownNo matter how easy it appearsExample : heartbleed

Ensure that implementation involved crypto specialistsFor the designand for the review

If possible: implementation should be FIPS 140-2certified


Always ensure data integrity andauthenticity

Encryption must be combined with data integrityOtherwise the ciphertext can be changedEspecialy over untrested chanel (e.g. URL or cookie)

Use crpytographic cipher modes that offer bothconfidentiality and authenticity

CCM, GCM, OCB

If not combine encryption in cipher-block chaining modeCDC with MAC

Message Authentication Code : HMAC, UMACDo not use ECB mode


Store passwords hashed and salted

Clear textVulnerable to SQL injection and the like

Just hashedPresent in rainbow tables

Hashed with a user specific hashAttack must be conducted for each of the users


Ensure that any secret key isprotected from unauthorized access

Define a key lifecycle

Store unencrypted keys away from the encrypted data

Use independent keys when multiple keys are required

Protect keys in a key vault

Document concrete procedures for managing keysthrough the lifecycle

Build support for changing keys periodically


A7 - Insufficient Attack Protection


A9 - Using components with knownvulnerabilities


A9 - Using components with knownvulnerabilities

Normal programs use softwares and librariesServerFramework librariesJavaScript library

Exploits are well knownCan be exploited by automatied toolsExpends the threat agent pool (script kidies for instance)

Example 1: Apache CXF Authentication BypassFalling to provide an identity tocken: invoke any web servicewith full permition

Example 2: Spring Remote Code ExecutionAbuse of EL language: execute arbitrary code


A10 - Underprotected APIs


Modern Architecture

RichClient(JS,mobile,…)

ServerAPI

EvilProgram

Data-Base

Filesystem


Examples of API

Rich client is connected to an API

Rich Client:Browser, mobile app, desktop application

Backend APIXML, JSON, RPC (remote procedure call), GWT, custom API

Specificity:Both parts have been developed togetherMaybe by the same person.


Google Web Toolkit (GWT) IJava on the Client

Code is compiled into .class.class is compiled into JavaScript

function Xm(a,b,c,d){var e,f;bn(a,b,c);e=(f=a.c.↘

→b.b.rows[b].cells[c],Qm(a,f,d==null),f);d!=null↘

→&&((fd(),e).textContent=d||zv,undefined)}

function $o(a){var b,c,e;c=ck(a.l);b=Yl(this,a);↘

→b&&this.e.removeChild((e=(fd(),c).parentNode,(!↘

→e||e.nodeType!=1)&&(e=null),e));return b}

function Lc(a){var b,c,d;d=zv;a=Kq(a);b=a.↘

→indexOf(Zv);if(b!=-1){c=a.indexOf($v)==0?8:0;d=↘

→Kq(a.substr(c,b-c))}return d.length>0?d:_v}

Java on the ServerProgram is written in JavaEmbedded into a Servlet engine.Remote Procedure Call (RPC) is done using serialized objects


Google Web Toolkit (GWT) II

CommunicationSame Objects are used on both sidesCall for “asynchrone function”, Objects are serialized and sent

Eavesdrop communicationIf communication uses HTTP: listen using WiresharkIf communication uses HTTPS: use a tool showingcommunication (OWASP ZAP, Firefox developer’s tool, ...)


Any vulnerabilitie may occur

Scenario #1Mobile banking App, connecting XML API of the bankAttacker reverse engineers the protocol:Account number is passed as part of authentication requesttogether with username and passwordAttacker tries: valide username and password, other accountnumberAttacker may control the account!

Scenario #2Public API for sending SMSContains a “transactionid” fieldit is concatenated into a SQL query without escaping orparameterizingAttacker can SQL-inject the server


Protection

Ensure secure communicationBetween client and API: use only HTTPS

Ensure that you have a strong authentication scheme foryour APIs

all credentials, keys, and tokens have been secured.

Ensure that whatever data format your requests use,that the parser configuration is hardened against attack.

Implement an access control scheme that protects APIsfrom being improperly invoked

it includes unauthorized function and data references.

Protect against injection of all forms

Be sure your security analysis and testing covers all yourAPIs and your tools can discover and analyze them alleffectively.


Security Risks vs. Attacks


Security Risks vs. Attacks

We have presented critical security risks of WebApplications

The application AS IS offers entry points to some attacksIt is a way to see what is to protect

AttacksOften combine many vulnerabilitiesWork also at the level of consequences


Example of Attacks

PhishingAttract user on a web site while he think he is somewhere elseCombines Cross Site ScriptingWear or non-existent authentication or authorization checks

Privacy ViolationIs the result of:

poor validationpoor business ruleweak authorization checks

Identity Theft

System compromise, data alteration, or data destruction


Security vs. Privacy Protection

Protecting web sitesProduces a lot of logsLog file analysis => Attacker detection

Protection of Legitimate Users privacyEU directive on Data Protection protects the privacy of citizensIt may be illegal to log that much data

Trade-off : What should be stored?Define a privacy policyEncrypt the log filesAuthorize only a restricted number of persons to access thelogsDestroy logs after some time (according to your data retentionpolicy).


Conclusion


Conclusion

Web Security belongs to securityEncryption,Testing of inputsTeaching of users

It is somehow differentRestricted entrypoint port 80 (may be more easy to protect)Open infrastructure (anybody can visit and attack)International ArchitectureNo control on the client


References


References

OWASP Top 10, The ten most critical Web ApplicationSecurity Vulnerabilities, 2013 Update, and 2017 RChttp://www.owasp.org/index.php/Category:

OWASP_Top_Ten_Project

Talk given at OWASP Switzerland (December 15,2015), Antonio Sanso (Adobe Research Switzerland)https://www.owasp.org/index.php/File:

20151215-Top_X_OAuth_2_Hacks-asanso.pdf


Documents

OWASP Top 10 - Benoist Top 10 Emmanuel Benoist ... Write Hardening guideline for your application Con guring all security mechanisms ... store using a public key, only backend program