Eoin Woods, profile picture
Uploaded byEoin Woods
201 views

API Vulnerabilties and What to Do About Them

The document provides an agenda and introduction for a presentation on API security. The agenda includes discussing the state of API security, introducing Software Security and OWASP, reviewing the top 10 API security risks, improving software security, and providing a summary. The introduction provides background on the presenter and an overview of Endava, the company he works for. It also lists Endava's global presence and industry expertise.

Embed presentation

Downloaded 17 times
Agenda 1. THE STATE OF API SECURITY 2. INTRODUCING SOFTWARE SECURITY AND OWASP 3. THE TOP 10 API SECURITY RISKS 4. IMPROVING SOFTWARE SECURITY 5. SUMMARY
Dr Eoin Woods – “Owen” CTO at Endava since 2015 • 1990 – 2003: Product companies in UK & US • 2003 – 2014: Capital Markets companies Been trying to bridge ”security” and “development” for a long time Author, speaker, community guy www.eoinwoods.info / @eoinwoodz
CLOSE TO CLIENT Denmark Germany Netherlands United Kingdom United States NEARSHORE DELIVERY European Union: Romania and Bulgaria Central European: North Macedonia, Moldova, and Serbia Latin America: Argentina, Colombia, Uruguay, and Venezuela 7,464 AS OF DEC 31, 2020 GLOBAL EMPLOYEES AS OF MAR 31, 2020 42 OFFICES // 39 CITIES // 19 COUNTRIES Banking & Financial Services Payments Insurance Investment Management Telco & Media Mobility Healthtech Retail & CPG FOCUSED INDUSTRY EXPERTISE
THE STATE OF API SECURITY 1
© 2021 EOIN WOODS // 20210101.1 Why Security Threats Matter • We need dependable systems even if things go wrong • Malice, Mistakes, Mischance • People are sometimes bad, careless or just unlucky • System security aims to mitigate these situations
TODAY’S THREAT LANDSCAPE • Internal applications exposed on the Internet • Introspection of APIs • Attacks being ”weaponized”
10 10 © 2021 EOIN WOODS // 20210310.1 DATA BREACHES 2005 - 2010 h t t p s : / / w w w . i n f o r m a t i o n i s b e a u t i f u l . n e t / v i s u a l i z a t i o n s / w o r l d s - b i g g e s t - d a t a - b r e a c h e s - h a c k s
11 11 © 2021 EOIN WOODS // 20210310.1 DATA BREACHES 2011 - 2015
12 12 © 2021 EOIN WOODS // 20210310.1 DATA BREACHES 2016-2020
© 2021 EOIN WOODS // 20210101.1 Applications 23% Crimeware 6% Cyber-Espionage 3% Denial of Service 62% Other 3% Payment Cards 2% Stolen Assets 1% The Importance of Application Security Verizon 2019 Data Breach Investigation report found applications were the root cause of about 25% of breaches Microfocus analysis of Fortify on Demand data found 93% of applications had a security bug Forrester 2019 survey suggests that 35% of security incidents had a webapp as a root cause https://enterprise.verizon.com/resources/reports/dbir https://www.microfocus.com/en-us/assets/security/application-security-risk-report https://www.forrester.com/report/The+State+Of+Application+Security+2019
© 2021 EOIN WOODS // 20210101.1 What do we mean by APIs? • We know APIs are as old as software • any interface to allow the invocation of one piece of software from another For this talk we’ll focus on network APIs • Any network accessible way of executing an operation on another piece of software • RPCs, RMIs, REST, GraphQL, … • In most cases we’re assuming a “REST style” API – e.g. JSON over HTTP
INTRODUCING SOFTWARE SECURITY & OWASP 2
17 17 © 2021 EOIN WOODS // 20210310.1 ASPECTS OF SECURITY PRACTICE SECURE SYSTEM OPERATION SECURE APPLICATION IMPLEMENTATION SECURE APPLICATION DESIGN SECURE INFRASTRUCTURE DESIGN SECURE INFRASTRUCTURE DEPLOYMENT
© 2021 EOIN WOODS // 20210101.1 Who are OWASP? The Open Web Application Security Project § Largely volunteer organisation, largely online Exists to improve the state of software security § Research, tools, guidance, standards § Runs local chapters for face-to-face meetings “OWASP Top 10” projects list top application security risks § OWASP Top 10 Webapp Security Risks § OWASP Top 10 Mobile Risks § OWASP Top 10 API Risks
© 2021 EOIN WOODS // 20210101.1 Other Key Security Organisations MITRE Corporation § Common Vulnerabilities and Exposures (CVE) § Common Weaknesses Enumeration (CWE) SAFECode § Fundamental Practices for Secure Software Development § Training There are a lot of others too (CPNI, CERT, CIS, ISSA, ISC2, …)
THE API TOP 10 SECURITY RISKS 3
© 2021 EOIN WOODS // 20210101.1 How was the 2019 API List Produced? Volunteer project of the OWASP organisation § 3 authors, ~35 contributors § https://www.owasp.org/index.php/OWASP_API_Security_Project First version in 2019 so less mature than the WebApp Top 10 § Initial analysis of public data sets (e.g. vulnerabilities & bug bounty data) § Penetration testing practitioners surveyed for their own ”top 10s” § Top 10 resulted from a consensus between data and surveys § Expert review provided refinement § Some work to do to achieve full conceptual consistency and coherence Future plan to extend a public call for data (like the WebApp set)
© 2021 EOIN WOODS // 20210101.1 OWASP API Top 10 - 2019 #1 Broken Object Authorization #2 Broken User Authentication #3 Excessive Data Exposure #4 Resources & Rate Limiting #5 Broken Function Authorization #6 Mass Assignment #7 Security Misconfiguration #8 Injection #9 Improper Asset Management #10 Insufficient Logging and Monitoring SOME MAY LOOK “OBVIOUS” BUT APPEAR ON THE LIST YEAR AFTER YEAR, BASED ON REAL VULNERABILITY DATA!
© 2021 EOIN WOODS // 20210101.1 OWASP API Top 10 - 2019 #1 Broken Object Authorization #2 Broken User Authentication #3 Excessive Data Exposure #4 Resources & Rate Limiting #5 Broken Function Authorization #6 Mass Assignment #7 Security Misconfiguration #8 Injection #9 Improper Asset Management #10 Insufficient Logging and Monitoring SOME MAY LOOK “OBVIOUS” BUT APPEAR ON THE LIST YEAR AFTER YEAR, BASED ON REAL VULNERABILITY DATA! Some are closely related to the Webapp Top 10 A few surprising omissions (e.g. vulnerable components)
© 2021 EOIN WOODS // 20210101.1 #1 Broken Object-Level Authorisation • After authentication many APIs don’t fully authorise access to resources • To make matters worse object ”keys” are often predictable or accessible $> wget https://aprovider.com/era/reports/1224459/monthly-latest • What would happen if you tried 1224470? • Hopefully the API would recognise that you weren’t authorised to view it • It turns out that many don’t! • Mitigations: enforce object authorisation for every request, well structured API design making need for authorisation clearer, long random object keys, testing Exploitability 3 Prevalence 3 Detectability 2 Technical 3
26 26 © 2021 EOIN WOODS // 20210310.1 #1 Broken Object-Level Authorisation Example: Parler Parler.com servers Parler App https://medium.com/swlh/exposing-the-riot-parler-api-mistakes-9a4db4e905d5 https://github.com/d0nk/parler-tricks https://github.com/daniel-centore/ParlerScraper authorisation point attacker (@donk_enby) no authorisation needed authentication point api.parler.com/v2/login/new Exploitability 3 Prevalence 3 Detectability 2 Technical 3
27 27 © 2021 EOIN WOODS // 20210310.1 #2 Broken User Authentication Exploitability 3 Prevalence 2 Detectability 2 Technical 2 • A range of possible problems rather than a single weakness • Allowing “credential stuffing” • Accepting weak passwords => brute-force credential attacks • Revealing authentication information in the API structure (e.g. URL) • Missing or incorrect validation of authentication tokens (e.g. JWT) • Mistakes in protocol implementation (very easy to do !) • Example: see example #10
28 28 © 2021 EOIN WOODS // 20210310.1 #2 Broken User Authentication Exploitability 3 Prevalence 2 Detectability 2 Technical 2 • Mitigations: • Multi-factor authentication for humans • Controls around login & credential recovery (e.g. password rules, lockout periods after failures, captchas, rate limiting) • Use proven, tested authentication mechanisms • Take time to understand any sophisticated security technologies • Careful implementation with expert design and code review • Functional and penetration testing
29 29 © 2021 EOIN WOODS // 20210310.1 #3 Excessive Data Exposure Exploitability 3 Prevalence 2 Detectability 2 Technical 2 • APIs often return more data that is required by the client • client-side filtering hides this from the user but not from software • API developers don’t always know what the client needs • or are trying to provide a more general solution to avoid rework • Sometimes an assumption that the client is ”trusted” • analogous problem to browser-side security in webapps • Problem often not obvious unless you know the data • automated tools aren’t going to spot this
30 30 © 2021 EOIN WOODS // 20210310.1 #3 Excessive Data Exposure Exploitability 3 Prevalence 2 Detectability 2 Technical 2 Example: Facebook Marketplace (2019) https://www.7elements.co.uk/resources/blog/facebooks-burglary-shopping-list/ "location": { "latitude": 54.9942235, "longitude": -1.6041244, "reverse_geocode": { "city": ”Newcastle upon Tyne", "state": ”England", "postal_code": "" }, "reverse_geocode_detailed": { "city": ”Newcastle upon Tyne", "state": ”England", "postal_code": ”NE2 2DS" } }
31 31 © 2021 EOIN WOODS // 20210310.1 #3 Excessive Data Exposure Exploitability 3 Prevalence 2 Detectability 2 Technical 2 • Mitigations • Assume the client is untrusted when developing an API • Always use the ”need to know” principle when designing data types • needs understanding of the context of the API request § Don’t return serialised forms of internal types • can leak information over time • use specifically designed return types with the right data items § Identify sensitive information classes (e.g. PII, card data, …) and have a specific review of any API call that accesses this information
32 32 © 2021 EOIN WOODS // 20210310.1 #4 Resources and Rate Limiting Exploitability 2 Prevalence 3 Detectability 3 Technical 2 • Classical DoS attacks use network protocols (e.g. SYN flood) • APIs are also vulnerable to overload attacks • can be exacerbated by the right (excessive) parameter values • e.g. parallel upload of multi-GB binary files • Two dimensions • Number of parallel requests allowed • Quantity of resources each request can be allocated • Mitigations: • Rate limiting at API level (spike limit, limit in time interval) • Rate limiting at session or user level (ditto) • Hard limits on parameter values and sizes • Runtime limits on memory, CPU, file descriptors, …
33 33 © 2021 EOIN WOODS // 20210310.1 #4 Resources and Rate Limiting Exploitability 2 Prevalence 3 Detectability 3 Technical 2 $> wget https://svc.com/inv/item?name=%22%2a%22&maxsize=9999999 • Hopefully this gets stopped immediately by a validation check • Or overridden within the API by an internal maximum • Unfortunately, quite a few APIs don’t always do this • Result is likely to be a large database result set and a huge amount of memory used => a runtime failure
34 34 © 2021 EOIN WOODS // 20210310.1 #5 Broken Function-Level Authorisation Exploitability 3 Prevalence 2 Detectability 1 Technical 2 • Incomplete or incorrect authorisation checks when API called • like #1 (object-level authorisation) a range of possible problems • Rarely totally missing, usually “holes” in the implementation • Frequently a result of a complex security model or API design • “correct” is complex, given interaction of authentication, roles, sensitivity levels, … • Can be due to complexity of application or 3rd party component • e.g. declarative security rules can often contain subtle problems • e.g. “falling through” logic which ends up providing access by mistake
35 35 © 2021 EOIN WOODS // 20210310.1 #5 Broken Function-Level Authorisation Exploitability 3 Prevalence 2 Detectability 1 Technical 2 Example: NewRelic “delete filterset” vulnerability To create a NR “filter set” you call POST https://infrastructure.newrelic.com/accounts/12345/settings/filterSets … passing a parameter block defining the new filter set. It turns out that calling … DELETE https://infrastructure.newrelic.com/accounts/12345/settings/filterSets … could delete the filter set without checking the user is authorised to do so https://www.cloudvector.com/owasp-api-security-top-10- broken-function-level-authorization/
36 36 © 2021 EOIN WOODS // 20210310.1 #5 Broken Function-Level Authorisation Exploitability 3 Prevalence 2 Detectability 1 Technical 2 • Mitigations • Simple as possible in design and implementation • Highlight sensitive operations for specific review • Thorough automated functional testing of authorisation • Take time to understand sophisticated security technology • Don’t invent your own security technology (again) • Always default to “no access”
38 38 © 2021 EOIN WOODS // 20210310.1 #6 Mass Assignment Exploitability 2 Prevalence 2 Detectability 2 Technical 2 • Different fields in a data entity often have different sensitivities • We often use libraries to “bind” data elements to and from API parameter sets • var item = JSON.parse(json_str); // JavaScript • // Java with Jackson Trade t = mapr.readObject(jsonStr, Trade.class); • Client could add “rogue” fields to overwrite sensitive state
39 39 © 2021 EOIN WOODS // 20210310.1 #6 Mass Assignment Example: the Harbor privilege escalation vulnerability Harbor: ”Our mission is to be the trusted cloud native repository for Kubernetes” Unfortunately, their product contained a privilege escalation vulnerability: POST /api/users HTTP/1.1 { “username”:”test”, ”email”:”test123@gmail.com”, ”realname”:”no name”, ”password”:”password1u0021″, ”comment”:null, “has_admin_role”:”true” } … due to a JSON mass assignment operation in JavaScript! https://unit42.paloaltonetworks.com/critical-vulnerability-in-harbor- enables-privilege-escalation-from-zero-to-admin-cve-2019-16097/ Exploitability 2 Prevalence 2 Detectability 2 Technical 2
40 40 © 2021 EOIN WOODS // 20210310.1 #6 Mass Assignment - Example Simple filtering example: function filterProperties(propList, obj) { for (var p in obj) { if (!obj.hasOwnProperty(p)) continue ; if (propList.indexOf(p) === -1) { delete obj[p]; } } } var fieldList = [‘name’, ‘cpid’, ‘price’, // … ]; filterProperties(fieldList, accountItem) { name: ‘My Customer', cpid: '1234234', price: 12.54, agentNotes: 'ZnVuY3Rpb24gZmlsdGVyUHJvcGVy dGllcyhwcm9wTGlzdCwgb2JqKSB7C iAgZm9yICh2YXIgcCBpbiBvYmopIH sKICAgIGlmICghb2JqLmhhc093blB yb3BlcnR5KHApKSBjb250aW51ZTsK ICAgIGlmIChwcm9wTGlzdC5pbmRle E9mKHApID09PSAtMSkgewogICAgIC BkZWxldGUgb2JqW3BdOwogICAgfQo gIH0KfQ==' } { name: ‘My Customer', cpid: '1234234', price: 12.54, }
41 41 © 2021 EOIN WOODS // 20210310.1 #6 Mass Assignment Exploitability 2 Prevalence 2 Detectability 2 Technical 2 • Mitigation: • Be careful when using automatic data binding libraries • Use specific types for API definition and explicit code to extract values and apply them to system state • Have ”whitelists” for fields that can be updated by a client
42 42 © 2021 EOIN WOODS // 20210310.1 #7 Security Misconfiguration Exploitability 3 Prevalence 3 Detectability 3 Technical 2 • Again a class of problem rather than a single cause • Missing security patches • Incorrect authorisation configuration • Unnecessary features enabled • Security enforcement (e.g. requiring TLS) incorrect or missing • Exposing sensitive information (e.g. 500 error stack traces!) • Mitigation • Testing (automated security tests, manual penetration testing) • Automated configuration and deployment for consistency • Expert review and code scanning throughout projects • Careful error handling
43 43 © 2021 EOIN WOODS // 20210310.1 #7 Security Misconfiguration Exploitability 3 Prevalence 3 Detectability 3 Technical 2 Example: Algolia Search $> curl https://myappid-dsn.algolia.net/1/keys/APIKEY?x-algolia- application-id=myappid&x-algolia-api-key=a7hw7gsh273hrk382 { ”value”: ‘.....’, “createdAt”: 15173453234, “acl” : [“search”, “addObject”, … ”editSettings”, “listIndexes”, …] } It turns out that many people accidentally use their admin API key for client API calls because of the way that Algolia’s documentation is written. https://www.secjuice.com/api-misconfiguration-data-breach
44 44 © 2021 EOIN WOODS // 20210310.1 #7 Security Misconfiguration Exploitability 3 Prevalence 3 Detectability 3 Technical 2 Example: Capital One https://krebsonsecurity.com/tag/capital-one-breach Capital One VPC M o d S e c u r i t y AWS S3 Bucket AWS EC2 VM $ > a w s i a m l i s t - r o l e s $ > … P E % { R E Q B O D Y _ P R O C E S S O R _ E R R O R } , B Q % { M U L T I P A R T _ B O U N D A R Y _ Q U O T E D } , B W % { M U L T I P A R T _ B O U N D A R Y _ W H I T E S P A C E } , D B % { M U L T I P A R T _ D A T A _ B E F O R E } , D A % { M U L T I P A R T _ D A T A _ A F T E R } , H F % { M U L T I P A R T _ H E A D E R _ F O L D I N G } , L F % { M U L T I P A R T _ L F _ L I N E } , M o d S e c u r i t y C o n f i g u r a t i o n • M i s t a k e i n M o d S e c u r i t y a l l o w e d a t t a c k e r i n t o V M • I A M m i s c o n f i g u r a t i o n a l l o w e d a c c e s s t o S 3 # ModSecurity (default) configuration SecRuleEngine DetectionOnly SecRequestBodyAccess On SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap+|/)|text/)xml" "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML" SecRule REQUEST_HEADERS:Content-Type "application/json" "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON" SecRequestBodyLimit 13107200 SecRequestBodyNoFilesLimit 131072 SecRequestBodyLimitAction Reject SecRule REQBODY_ERROR "!@eq 0" "id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.’, logdata:'%{reqbody_error_msg}',severity:2" SecRule MULTIPART_STRICT_ERROR "!@eq 0" "id:'200003',phase:2,t:none,log,deny,status:400, msg:'Multipart request body failed strict validation: PE %{REQBODY_PROCESSOR_ERROR}, BQ %{MULTIPART_BOUNDARY_QUOTED}, BW %{MULTIPART_BOUNDARY_WHITESPACE}, DB %{MULTIPART_DATA_BEFORE}, DA %{MULTIPART_DATA_AFTER}, HF %{MULTIPART_HEADER_FOLDING}, LF %{MULTIPART_LF_LINE}, SM %{MULTIPART_MISSING_SEMICOLON}, IQ %{MULTIPART_INVALID_QUOTING}, IP %{MULTIPART_INVALID_PART}, IH %{MULTIPART_INVALID_HEADER_FOLDING}, FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'" SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'" SecPcreMatchLimit 1000 SecPcreMatchLimitRecursion 1000 SecRule TX:/^MSC_/ "!@streq 0" "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
45 45 © 2021 EOIN WOODS // 20210310.1 #8 Injection Exploitability 3 Prevalence 2 Detectability 3 Technical 3 • Our old friend from the Webapp Top 10! • Dangerous in APIs as well as in webapps • Anything interpreted can be injected: • Database query parameters • Command line arguments • Configuration items that are parsed and processed
46 46 © 2021 EOIN WOODS // 20210310.1 #8 Injection Exploitability 3 Prevalence 2 Detectability 3 Technical 3 Example: check parameters and avoid direct SQL String tradeId = req.path().param(“tradeid”); ESAPI.validator().getValidInput(“tradeId”, tradeId, “HTTPParameterValue”, 12, false, true); String query = “select id, ccy, value, … from trade where id=?” ; PreparedStatement ps = conn.prepareStatement(query); ps.setString(1, tradeId); ResultSet results = ps.executeQuery() ;
47 47 © 2021 EOIN WOODS // 20210310.1 #8 Injection Exploitability 3 Prevalence 2 Detectability 3 Technical 3 • Mitigation: • Validate and sanitise all data entering the system • Use a single, well-tested, validation library to make validation reliable and straightforward (“easy thing” == “what is actually done”) • Where possible use APIs rather than interpreters (e.g. bind parameters for “prepared” database queries not query strings) • Sanity check result payloads (e.g. maximum size checks) • Strongly type API interfaces and enforce types strictly
48 48 © 2021 EOIN WOODS // 20210310.1 #9 Improper Asset Management Exploitability 3 Prevalence 3 Detectability 2 Technical 2 • Many application estates today are not well understood • Old applications can run for years with little attention • Will contain vulnerabilities in old software components • Often skipped during software security remediation work • Can have deliberate or accidental vulnerabilities themselves • Compromises may not be noticed • Sometimes important applications have old neglected features • Old data interfaces left in place for backwards compatibility • Unsupported opensource components to avoid regression testing • Insecure mechanisms (e.g. FTP file transfer) to avoid touching other old applications
49 49 © 2021 EOIN WOODS // 20210310.1 #9 Improper Asset Management Exploitability 3 Prevalence 3 Detectability 2 Technical 2 • New applications can also introduce problems if not understood • Microservices introduce many moving parts with network interfaces • Cloud allows application teams to deploy new applications and infrastructure quickly and independently … and perhaps insecurely • Rate of change in modern application estates can make keeping track of the estate difficult if not automated … tomorrow’s legacy
50 50 © 2021 EOIN WOODS // 20210310.1 #9 Improper Asset Management Exploitability 3 Prevalence 3 Detectability 2 Technical 2 Example: application evolution Monolithic Core «REST» Microservice 1 «REST» Microservice 2 «REST» «JSON/JMS» «XML/MQ» «SOAP/HTTP» Today’s main interfaces Yesterday’s legacy
© 2021 EOIN WOODS // 20210101.1 #9 Improper Asset Management Example: the scale problem Large organisations have thousands of applications, servers, services, message queues, databases, … … all constantly changing Exploitability 3 Prevalence 3 Detectability 2 Technical 2
52 52 © 2021 EOIN WOODS // 20210310.1 #9 Improper Asset Management Exploitability 3 Prevalence 3 Detectability 2 Technical 2 • Mitigation: • There are no easy mitigations once in this situation! • Easy to say, but avoidance is the most effective mitigation • Finding these applications and features is often the most difficult part • Network scanning can be useful to find unexpected end points • Once found, investing in modernisation, improving security or retirement are all options • Automate maintenance of application and infrastructure inventories wherever possible
53 53 © 2021 EOIN WOODS // 20210310.1 #10 Insufficient Logging & Monitoring Exploitability 2 Prevalence 3 Detectability 1 Technical 2 • Another familiar “friend” from the Webapp Top 10 • Logging and monitoring rarely comes ”for free” with APIs • therefore it often gets forgotten or deprioritised • Poor logging and monitoring technology, implementation or practices means it is difficult to detect and respond to suspicious activity • e.g. you find that an API credential has been compromised for several days … do you know what that credential has been used for while compromised?
54 54 © 2021 EOIN WOODS // 20210310.1 #10 Insufficient Logging & Monitoring Exploitability 2 Prevalence 3 Detectability 1 Technical 2 • Example: the need for monitoring Webapp automated credential stuffing attack database access through injection attack exfiltration of bulk data Monitoring could alert to all three aspects of the attack: • login failure monitoring • excessive database result set • unusual large outbound transfer
55 55 © 2021 EOIN WOODS // 20210310.1 #10 Insufficient Logging & Monitoring Exploitability 2 Prevalence 3 Detectability 1 Technical 2 • Mitigation … all well known solutions • Log all security sensitive events (authentication activity, access failures, validation failures, …) • Keep logs accessible but secure • Use SEIM systems to aggregate the logs from different sources • Build awareness of ”normal” and create dashboards for security related metrics to allow ”abnormal” to be spotted
© 2021 EOIN WOODS // 20210101.1 Summary of Vulnerability Types • Injection • SQL, configuration, operating system command, … • Inadequate validation • Of authentication to confirm identity of caller • Of authorisation to access resources • Accepting unexpected inputs (e.g. unnecessary fields, excessive parameter lengths) • Implementation mistakes • Returning too much data • Incomplete or faulty authorisation checks • Blindly binding data structures to inputs • Environment problems • Need for rate limiting • Monitoring and logging • Careful configuration of the entire stack
IMPROVING SOFTWARE SECURITY 4
59 59 © 2021 EOIN WOODS // 20210310.1 Security Awareness Security Design Secure Implementation Security Testing Some Key Aspects of Software Security for Teams Entire team Security requirements Threat modelling Security design Secure design Secure implementation Functional security tests Code reviews SCA Static analysis Dynamic testing (DAST) Penetration testing
60 60 © 2021 EOIN WOODS // 20210310.1 Securing an API API FUNCTIONS A U T H O R I S A T I O N ( A C C E S S C O N T R O L ) A U D I T I N G A U T H E N T I C A T I O N R A T E L I M I T I N G Volume Identity Records Access
61 61 © 2021 EOIN WOODS // 20210310.1 auth code Over TLS A W S A P I G a t e w a y rate limiting A P I F u n c t i o n Securing an API - Example AWS Java + Spring process A u d i t L o g g i n g F i l t e r AWS Cloud Watch centralised logging A u t h o r i s a t i o n P r o x y application authorisation check API Client Okta OAuth2 Service (Authentication & Authorization Service) login for auth code A u t h e n t i c a t i o n F i l t e r authenticate w/auth code to get access token A u t h o r i s a t i o n F i l t e r API access check via token
62 62 © 2021 EOIN WOODS // 20210310.1 Lots of Choice When Securing an API A u t h e n t i c a t i o n & A u t h o r i s a t i o n Local implementation (users, passwords, groups, ACLs) Cloud services (AWS Cognito, Azure AD, …) 3rd party services (Auth0, Okta, …) Enterprise products (IAM vendors) Open source (Keycloak, Gluu, …) A u d i t i n g Plain files OS logging Database records Cloud services (CloudWatch, Azure Monitor) SIEM (Splunk, Rapid 7, …) R a t e L i m i t i n g Cloud API gateways Enterprise API gateways Reverse proxies Open source middleware
© 2021 EOIN WOODS // 20210101.1 Key Tactics • Don’t trust clients • authentication, authorisation, validation • Identify “interpreters” and sanitise inputs, use bind variables, … • command lines, database queries, configuration data, … • Protect valuable information at rest and in transit • encryption • Simplicity • Avoid the special cases, make sure the system is understood • Standardise and Automate • consistency, correctness, avoid configuration errors
© 2021 EOIN WOODS // 20210101.1 Tactic: Don’t Trust Clients • Be wary of everything sent by a client • Assume possible tampering • TLS connections • short lived sessions • reauthenticate humans, recheck tokens before sensitive operations • use opaque tokens for IDs • validate everything
© 2021 EOIN WOODS // 20210101.1 Tactic: Watch Out for Injection • Many things are interpreters • Operating system shells • Database query languages • Configuration files • Parsers • Assume someone will notice! • Avoid using direct string manipulation • libraries and bind variables • Sanitise strings passed to interpreters • 3rd party library (e.g. OWASP) • Reject very long strings
© 2021 EOIN WOODS // 20210101.1 Tactic: Protect Information • Assume perimeter breach • defence in depth • encrypt everything possible • But there are tradeoffs • slows everything down • querying is difficult • Message routing on sensitive fields • Manage and rotate keys • Complexity added to restore
© 2021 EOIN WOODS // 20210101.1 Tactic: Simplify and Standardise • Complexity is the enemy of security • “you can’t secure what you don’t understand” • special cases often forgotten • Simplify, standardise, automate • Simple things easier to check & secure • Standardisation removes a lot of special cases • Automation removes human inconsistencies avoiding one area of risk
© 2021 EOIN WOODS // 20210101.1 A Few Words on Tools • Security tools are obviously useful • Many types exist from simple to very complex • Need make sure people don’t view tools as an alternative to thinking! • Main groups • Specialist security scanning tools • Interactive tools for penetration and exploratory testing • Software composition analysis (open source scanning)
© 2021 EOIN WOODS // 20210101.1 Automated Security Testing • Automated tools are useful for some types of security problem • SAST – static scanning • DAST – simulated attacks • IAST – agent-based monitoring • RASP – runtime security monitoring • Challenges are false positives and effort to mitigate if used late • Danger of over-reliance
© 2021 EOIN WOODS // 20210101.1 Postman • API development & testing suite • Popular for functional and security API testing • Desktop tool with link to cloud service (with a web UI) • Interactive or command line (via ”Newman” runner extension) https://www.postman.com/
© 2021 EOIN WOODS // 20210101.1 BurpSuite • Proxy, scanning, pentest tool • Very capable free version • Fuller commercial version available • Inspect traffic, manipulate headers and content, replay, spider, … • Made in Knutsford! http://portswigger.net/burp
© 2021 EOIN WOODS // 20210101.1 Metasploit • The pentester’s ”standard” tool • Very wide range of capabilities • Commercial version available https://www.metasploit.com HTTPS://WWW.METASPLOIT.COM
© 2021 EOIN WOODS // 20210101.1 Open Source Scanning • Example commercial tools for OSS security, audit & compliance: • BlackDuck • Whitesource • Sonatype LCM • Snyk • Scan builds identifying open source • Checks for known vulnerabilities • Alerts and dashboards for monitoring www.blackduck.com www.whitesourcesoftware.com www.sonatype.com/nexus-lifecycle www.snyk.io
SUMMARY 5
© 2021 EOIN WOODS // 20210101.1 OWASP API Top 10 - 2019 #1 Broken Object Authorization #2 Broken User Authentication #3 Excessive Data Exposure #4 Resources & Rate Limiting #5 Broken Function Authorization #6 Mass Assignment #7 Security Misconfiguration #8 Injection #9 Improper Asset Management #10 Insufficient Logging and Monitoring SOME MAY LOOK “OBVIOUS” BUT APPEAR ON THE LIST YEAR AFTER YEAR, BASED ON REAL VULNERABILITY DATA!
77 77 © 2021 EOIN WOODS // 20210310.1 Key Aspects of API Security Preventing Injection • SQL, configuration, commands, ... Validation • inputs, outputs, authentication, authorisation Implementation • automatic binding, too much data, faulty checking Environment • rate limiting, monitoring, logging, configuration
78 78 © 2021 EOIN WOODS // 20210310.1 Elements of Securing an API API Function Authorisation Authentication Rate Limiting Auditing
79 79 © 2021 EOIN WOODS // 20210310.1 Useful Tactics for API Security Don’t trust clients Watch out for injection Protect information Simplify and standardise
80 80 © 2021 EOIN WOODS // 20210310.1 Books
API Vulnerabilties and What to Do About Them

More Related Content

PPTX
Secure coding practices
byMohammed Danish Amber
 
PPTX
VAPT PRESENTATION full.pptx
byDARSHANBHAVSAR14
 
PPTX
DEVSECOPS.pptx
byMohammadSaif904342
 
PDF
Penetration Testing Tutorial | Penetration Testing Tools | Cyber Security Tra...
byEdureka!
 
PPTX
Vulnerabilities in modern web applications
byNiyas Nazar
 
PDF
DevSecOps Jenkins Pipeline -Security
byn|u - The Open Security Community
 
PDF
Burp suite
byYashar Shahinzadeh
 
PPTX
Secure Software Development Life Cycle
byMaurice Dawson
 
Secure coding practices
byMohammed Danish Amber
 
VAPT PRESENTATION full.pptx
byDARSHANBHAVSAR14
 
DEVSECOPS.pptx
byMohammadSaif904342
 
Penetration Testing Tutorial | Penetration Testing Tools | Cyber Security Tra...
byEdureka!
 
Vulnerabilities in modern web applications
byNiyas Nazar
 
DevSecOps Jenkins Pipeline -Security
byn|u - The Open Security Community
 
Burp suite
byYashar Shahinzadeh
 
Secure Software Development Life Cycle
byMaurice Dawson
 

What's hot

PPTX
OWASP Top 10 2021 Presentation (Jul 2022)
byTzahiArabov
 
PPTX
Kali linux
byHarsh Gor
 
PPTX
Deep understanding on Cross-Site Scripting and SQL Injection
byVishal Kumar
 
PPT
Introduction to Web Application Penetration Testing
byAnurag Srivastava
 
PPTX
WTF is Penetration Testing v.2
byScott Sutherland
 
PPTX
Intro to exploits in metasploitand payloads in msfvenom
bySiddharth Krishna Kumar
 
PDF
Demystifying DevSecOps
byArchana Joshi
 
PPTX
Secure coding practices
byScott Hurrey
 
PPTX
Introduction to kubernetes
byRishabh Indoria
 
PPTX
Abusing Microsoft Kerberos - Sorry you guys don't get it
byBenjamin Delpy
 
PPTX
Kali presentation
byZain Ul abadin
 
PPTX
Introduction to DevOps
byHawkman Academy
 
PDF
OWASP Top 10 Web Application Vulnerabilities
bySoftware Guru
 
PPTX
CISSP - Software Development Security
byKarthikeyan Dhayalan
 
PPTX
Installing and Configuring NGINX Open Source
byNGINX, Inc.
 
PPTX
Security testing fundamentals
byCygnet Infotech
 
PDF
API Security - OWASP top 10 for APIs + tips for pentesters
byInon Shkedy
 
PDF
Practical DevSecOps Course - Part 1
byMohammed A. Imran
 
PPTX
Benefits of DevSecOps
byFinto Thomas , CISSP, TOGAF, CCSP, ITIL. JNCIS
 
PPTX
MicroServices on Azure
bySergey Seletsky
 
OWASP Top 10 2021 Presentation (Jul 2022)
byTzahiArabov
 
Kali linux
byHarsh Gor
 
Deep understanding on Cross-Site Scripting and SQL Injection
byVishal Kumar
 
Introduction to Web Application Penetration Testing
byAnurag Srivastava
 
WTF is Penetration Testing v.2
byScott Sutherland
 
Intro to exploits in metasploitand payloads in msfvenom
bySiddharth Krishna Kumar
 
Demystifying DevSecOps
byArchana Joshi
 
Secure coding practices
byScott Hurrey
 
Introduction to kubernetes
byRishabh Indoria
 
Abusing Microsoft Kerberos - Sorry you guys don't get it
byBenjamin Delpy
 
Kali presentation
byZain Ul abadin
 
Introduction to DevOps
byHawkman Academy
 
OWASP Top 10 Web Application Vulnerabilities
bySoftware Guru
 
CISSP - Software Development Security
byKarthikeyan Dhayalan
 
Installing and Configuring NGINX Open Source
byNGINX, Inc.
 
Security testing fundamentals
byCygnet Infotech
 
API Security - OWASP top 10 for APIs + tips for pentesters
byInon Shkedy
 
Practical DevSecOps Course - Part 1
byMohammed A. Imran
 
Benefits of DevSecOps
byFinto Thomas , CISSP, TOGAF, CCSP, ITIL. JNCIS
 
MicroServices on Azure
bySergey Seletsky
 

Similar to API Vulnerabilties and What to Do About Them

PDF
2022 apidays LIVE Helsinki & North_Future proofing API Security
byapidays
 
PDF
APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...
byapidays
 
PDF
APIdays London 2019 - API Security Tips for Developers with Isabelle Mauny, 4...
byapidays
 
PDF
API Security Best Practices and Guidelines
byWSO2
 
PDF
apidays LIVE Paris 2021 - Addressing OWASP API Security Top 10 by Isabelle Ma...
byapidays
 
PDF
APISecurity_OWASP_MitigationGuide
byIsabelle Mauny
 
PDF
APIDays Paris Security Workshop
by42Crunch
 
PDF
Keamanan Digital dan Privasi di Masa Pandemi-Taro Lay (Director-Kalama Cyber)
byDicodingEvent
 
PDF
The API Primer (OWASP AppSec Europe, May 2015)
byGreg Patton
 
PDF
Checkmarx meetup API Security - API Security top 10 - Erez Yalon
byAdar Weidman
 
PPTX
How-to-Secure-APIs-to-Defend-Against-Emerging-Cyber-Threats-to-Digital-Web-As...
bykhalidmohammedfci
 
PDF
OWASPAPISecurity
byJie Liau
 
PDF
apidays New York 2023 - A decade of API breaches, courtesy of application fla...
byapidays
 
PDF
SecDevOps for API Security
by42Crunch
 
PDF
OWASP API Security Top 10 Examples
by42Crunch
 
PDF
apidays LIVE London 2021 - API Security challenges and solutions by Wadii Tah...
byapidays
 
PPTX
Navigating the Intersection: IAM and OWASP in the Cybersecurity Landscape (Id...
byDavid Brossard
 
PDF
OWASP API Security TOP 10 - 2019
byMiguel Angel Falcón Muñoz
 
PDF
apidays New York 2023 - Putting yourself out there - how to secure your publi...
byapidays
 
PPTX
apidays Paris 2024 - Layered Approach of API Security Strategies and its Busi...
byapidays
 
2022 apidays LIVE Helsinki & North_Future proofing API Security
byapidays
 
APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...
byapidays
 
APIdays London 2019 - API Security Tips for Developers with Isabelle Mauny, 4...
byapidays
 
API Security Best Practices and Guidelines
byWSO2
 
apidays LIVE Paris 2021 - Addressing OWASP API Security Top 10 by Isabelle Ma...
byapidays
 
APISecurity_OWASP_MitigationGuide
byIsabelle Mauny
 
APIDays Paris Security Workshop
by42Crunch
 
Keamanan Digital dan Privasi di Masa Pandemi-Taro Lay (Director-Kalama Cyber)
byDicodingEvent
 
The API Primer (OWASP AppSec Europe, May 2015)
byGreg Patton
 
Checkmarx meetup API Security - API Security top 10 - Erez Yalon
byAdar Weidman
 
How-to-Secure-APIs-to-Defend-Against-Emerging-Cyber-Threats-to-Digital-Web-As...
bykhalidmohammedfci
 
OWASPAPISecurity
byJie Liau
 
apidays New York 2023 - A decade of API breaches, courtesy of application fla...
byapidays
 
SecDevOps for API Security
by42Crunch
 
OWASP API Security Top 10 Examples
by42Crunch
 
apidays LIVE London 2021 - API Security challenges and solutions by Wadii Tah...
byapidays
 
Navigating the Intersection: IAM and OWASP in the Cybersecurity Landscape (Id...
byDavid Brossard
 
OWASP API Security TOP 10 - 2019
byMiguel Angel Falcón Muñoz
 
apidays New York 2023 - Putting yourself out there - how to secure your publi...
byapidays
 
apidays Paris 2024 - Layered Approach of API Security Strategies and its Busi...
byapidays
 

More from Eoin Woods

PDF
Democratising Software Architecture
byEoin Woods
 
PDF
Secure by Design - Security Design Principles for the Working Architect
byEoin Woods
 
PDF
A Breathless Tour of Blockchain
byEoin Woods
 
PDF
Models, Sketches and Everything In Between
byEoin Woods
 
PDF
Capturing Design (When you really have to)
byEoin Woods
 
PDF
Serverless Computing for the Inquiring Mind
byEoin Woods
 
PDF
Using Software Architecture Principles in Practice
byEoin Woods
 
PDF
Secure by Design - Security Design Principles for the Rest of Us
byEoin Woods
 
PDF
Software Architecture as Systems Dissolve
byEoin Woods
 
PDF
Software Architecture as Systems Dissolve (OOP2016)
byEoin Woods
 
PPTX
When Architecture Meets Data
byEoin Woods
 
PDF
System Security Beyond the Libraries
byEoin Woods
 
PDF
Getting Your System to Production and Keeping it There
byEoin Woods
 
PDF
Common WebApp Vulnerabilities and What to Do About Them
byEoin Woods
 
PDF
Deferring the Last Responsible Moment
byEoin Woods
 
Democratising Software Architecture
byEoin Woods
 
Secure by Design - Security Design Principles for the Working Architect
byEoin Woods
 
A Breathless Tour of Blockchain
byEoin Woods
 
Models, Sketches and Everything In Between
byEoin Woods
 
Capturing Design (When you really have to)
byEoin Woods
 
Serverless Computing for the Inquiring Mind
byEoin Woods
 
Using Software Architecture Principles in Practice
byEoin Woods
 
Secure by Design - Security Design Principles for the Rest of Us
byEoin Woods
 
Software Architecture as Systems Dissolve
byEoin Woods
 
Software Architecture as Systems Dissolve (OOP2016)
byEoin Woods
 
When Architecture Meets Data
byEoin Woods
 
System Security Beyond the Libraries
byEoin Woods
 
Getting Your System to Production and Keeping it There
byEoin Woods
 
Common WebApp Vulnerabilities and What to Do About Them
byEoin Woods
 
Deferring the Last Responsible Moment
byEoin Woods
 

Recently uploaded

PDF
DSD-INT 2025 Timor-Leste Flood exposure and Climate Change assessment - Ogunwumi
byDeltares
 
PPTX
Boost Productivity the Smart Way with AI Automation Solutions
byEllocent Labs
 
PPTX
Zotero Software Demonstration. Biomedical Perspective
byDr Snehashis Singha
 
PPTX
wAIred_LearnwithoutAI_KotlinDevDay_27112025.pptx
bySimonedeGijt
 
PDF
DSD-INT 2025 Building-Aware Flood and Lifeline Scour Modeling with Delft3D FM...
byDeltares
 
PPTX
Building AI agents in Java - Devoxx Belgium 2025
byJulien Dubois
 
PPTX
Building a RAG System for Customer Support - L1
byBogdan Mustata
 
PDF
DSD-INT 2025 Understanding the Paraguay River Response to Hard Bottom Dredgin...
byDeltares
 
PDF
DSD-INT 2025 Validation of SFINCS on Historical River Floods at the Global Sc...
byDeltares
 
PDF
SCORM Cloud: The 5 categories of content distribution
byRustici Software
 
PDF
Custom Software Development Presentation.pdf
byssuser9c7131
 
PDF
BCA 1st Semester Fundamentals Solved Question Paper 44121
byKuvempu University
 
PDF
DSD-INT 2025 Flood Early Warning System for the Trans-African Hydrometeorolog...
byDeltares
 
PDF
DSD-INT 2025 Climate and impact attribution of compound flooding induced by t...
byDeltares
 
PDF
DSD-INT 2025 DevOps - Automated testing and delivery of Delft3D FM - van West...
byDeltares
 
PDF
Smarter Testing Safer Systems Balancing AI and Oversight in Regulated Environ...
byApplitools
 
PDF
DSD-INT 2025 MeshKernel and D-Grid Editor - Stout
byDeltares
 
PPTX
Understanding-ROM-RAM-Cache-and-Buffer-Memory.pptx.pptx
bylata2850
 
PDF
DSD-INT 2025 Century-Scale Impacts of Sediment-Based Coastal Restoration unde...
byDeltares
 
PDF
Breaking the Vulnerability Management Cycle with Anchore and Echo
byAnchore
 
DSD-INT 2025 Timor-Leste Flood exposure and Climate Change assessment - Ogunwumi
byDeltares
 
Boost Productivity the Smart Way with AI Automation Solutions
byEllocent Labs
 
Zotero Software Demonstration. Biomedical Perspective
byDr Snehashis Singha
 
wAIred_LearnwithoutAI_KotlinDevDay_27112025.pptx
bySimonedeGijt
 
DSD-INT 2025 Building-Aware Flood and Lifeline Scour Modeling with Delft3D FM...
byDeltares
 
Building AI agents in Java - Devoxx Belgium 2025
byJulien Dubois
 
Building a RAG System for Customer Support - L1
byBogdan Mustata
 
DSD-INT 2025 Understanding the Paraguay River Response to Hard Bottom Dredgin...
byDeltares
 
DSD-INT 2025 Validation of SFINCS on Historical River Floods at the Global Sc...
byDeltares
 
SCORM Cloud: The 5 categories of content distribution
byRustici Software
 
Custom Software Development Presentation.pdf
byssuser9c7131
 
BCA 1st Semester Fundamentals Solved Question Paper 44121
byKuvempu University
 
DSD-INT 2025 Flood Early Warning System for the Trans-African Hydrometeorolog...
byDeltares
 
DSD-INT 2025 Climate and impact attribution of compound flooding induced by t...
byDeltares
 
DSD-INT 2025 DevOps - Automated testing and delivery of Delft3D FM - van West...
byDeltares
 
Smarter Testing Safer Systems Balancing AI and Oversight in Regulated Environ...
byApplitools
 
DSD-INT 2025 MeshKernel and D-Grid Editor - Stout
byDeltares
 
Understanding-ROM-RAM-Cache-and-Buffer-Memory.pptx.pptx
bylata2850
 
DSD-INT 2025 Century-Scale Impacts of Sediment-Based Coastal Restoration unde...
byDeltares
 
Breaking the Vulnerability Management Cycle with Anchore and Echo
byAnchore
 

API Vulnerabilties and What to Do About Them

  • 2.
    Agenda 1. THE STATEOF API SECURITY 2. INTRODUCING SOFTWARE SECURITY AND OWASP 3. THE TOP 10 API SECURITY RISKS 4. IMPROVING SOFTWARE SECURITY 5. SUMMARY
  • 3.
    Dr Eoin Woods– “Owen” CTO at Endava since 2015 • 1990 – 2003: Product companies in UK & US • 2003 – 2014: Capital Markets companies Been trying to bridge ”security” and “development” for a long time Author, speaker, community guy www.eoinwoods.info / @eoinwoodz
  • 4.
    CLOSE TO CLIENT Denmark Germany Netherlands UnitedKingdom United States NEARSHORE DELIVERY European Union: Romania and Bulgaria Central European: North Macedonia, Moldova, and Serbia Latin America: Argentina, Colombia, Uruguay, and Venezuela 7,464 AS OF DEC 31, 2020 GLOBAL EMPLOYEES AS OF MAR 31, 2020 42 OFFICES // 39 CITIES // 19 COUNTRIES Banking & Financial Services Payments Insurance Investment Management Telco & Media Mobility Healthtech Retail & CPG FOCUSED INDUSTRY EXPERTISE
  • 5.
    THE STATE OFAPI SECURITY 1
  • 6.
    © 2021 EOINWOODS // 20210101.1 Why Security Threats Matter • We need dependable systems even if things go wrong • Malice, Mistakes, Mischance • People are sometimes bad, careless or just unlucky • System security aims to mitigate these situations
  • 7.
    TODAY’S THREAT LANDSCAPE •Internal applications exposed on the Internet • Introspection of APIs • Attacks being ”weaponized”
  • 8.
    10 10 © 2021 EOINWOODS // 20210310.1 DATA BREACHES 2005 - 2010 h t t p s : / / w w w . i n f o r m a t i o n i s b e a u t i f u l . n e t / v i s u a l i z a t i o n s / w o r l d s - b i g g e s t - d a t a - b r e a c h e s - h a c k s
  • 9.
    11 11 © 2021 EOINWOODS // 20210310.1 DATA BREACHES 2011 - 2015
  • 10.
    12 12 © 2021 EOINWOODS // 20210310.1 DATA BREACHES 2016-2020
  • 11.
    © 2021 EOINWOODS // 20210101.1 Applications 23% Crimeware 6% Cyber-Espionage 3% Denial of Service 62% Other 3% Payment Cards 2% Stolen Assets 1% The Importance of Application Security Verizon 2019 Data Breach Investigation report found applications were the root cause of about 25% of breaches Microfocus analysis of Fortify on Demand data found 93% of applications had a security bug Forrester 2019 survey suggests that 35% of security incidents had a webapp as a root cause https://enterprise.verizon.com/resources/reports/dbir https://www.microfocus.com/en-us/assets/security/application-security-risk-report https://www.forrester.com/report/The+State+Of+Application+Security+2019
  • 12.
    © 2021 EOINWOODS // 20210101.1 What do we mean by APIs? • We know APIs are as old as software • any interface to allow the invocation of one piece of software from another For this talk we’ll focus on network APIs • Any network accessible way of executing an operation on another piece of software • RPCs, RMIs, REST, GraphQL, … • In most cases we’re assuming a “REST style” API – e.g. JSON over HTTP
  • 13.
  • 14.
    17 17 © 2021 EOINWOODS // 20210310.1 ASPECTS OF SECURITY PRACTICE SECURE SYSTEM OPERATION SECURE APPLICATION IMPLEMENTATION SECURE APPLICATION DESIGN SECURE INFRASTRUCTURE DESIGN SECURE INFRASTRUCTURE DEPLOYMENT
  • 15.
    © 2021 EOINWOODS // 20210101.1 Who are OWASP? The Open Web Application Security Project § Largely volunteer organisation, largely online Exists to improve the state of software security § Research, tools, guidance, standards § Runs local chapters for face-to-face meetings “OWASP Top 10” projects list top application security risks § OWASP Top 10 Webapp Security Risks § OWASP Top 10 Mobile Risks § OWASP Top 10 API Risks
  • 16.
    © 2021 EOINWOODS // 20210101.1 Other Key Security Organisations MITRE Corporation § Common Vulnerabilities and Exposures (CVE) § Common Weaknesses Enumeration (CWE) SAFECode § Fundamental Practices for Secure Software Development § Training There are a lot of others too (CPNI, CERT, CIS, ISSA, ISC2, …)
  • 17.
    THE API TOP10 SECURITY RISKS 3
  • 18.
    © 2021 EOINWOODS // 20210101.1 How was the 2019 API List Produced? Volunteer project of the OWASP organisation § 3 authors, ~35 contributors § https://www.owasp.org/index.php/OWASP_API_Security_Project First version in 2019 so less mature than the WebApp Top 10 § Initial analysis of public data sets (e.g. vulnerabilities & bug bounty data) § Penetration testing practitioners surveyed for their own ”top 10s” § Top 10 resulted from a consensus between data and surveys § Expert review provided refinement § Some work to do to achieve full conceptual consistency and coherence Future plan to extend a public call for data (like the WebApp set)
  • 19.
    © 2021 EOINWOODS // 20210101.1 OWASP API Top 10 - 2019 #1 Broken Object Authorization #2 Broken User Authentication #3 Excessive Data Exposure #4 Resources & Rate Limiting #5 Broken Function Authorization #6 Mass Assignment #7 Security Misconfiguration #8 Injection #9 Improper Asset Management #10 Insufficient Logging and Monitoring SOME MAY LOOK “OBVIOUS” BUT APPEAR ON THE LIST YEAR AFTER YEAR, BASED ON REAL VULNERABILITY DATA!
  • 20.
    © 2021 EOINWOODS // 20210101.1 OWASP API Top 10 - 2019 #1 Broken Object Authorization #2 Broken User Authentication #3 Excessive Data Exposure #4 Resources & Rate Limiting #5 Broken Function Authorization #6 Mass Assignment #7 Security Misconfiguration #8 Injection #9 Improper Asset Management #10 Insufficient Logging and Monitoring SOME MAY LOOK “OBVIOUS” BUT APPEAR ON THE LIST YEAR AFTER YEAR, BASED ON REAL VULNERABILITY DATA! Some are closely related to the Webapp Top 10 A few surprising omissions (e.g. vulnerable components)
  • 21.
    © 2021 EOINWOODS // 20210101.1 #1 Broken Object-Level Authorisation • After authentication many APIs don’t fully authorise access to resources • To make matters worse object ”keys” are often predictable or accessible $> wget https://aprovider.com/era/reports/1224459/monthly-latest • What would happen if you tried 1224470? • Hopefully the API would recognise that you weren’t authorised to view it • It turns out that many don’t! • Mitigations: enforce object authorisation for every request, well structured API design making need for authorisation clearer, long random object keys, testing Exploitability 3 Prevalence 3 Detectability 2 Technical 3
  • 22.
    26 26 © 2021 EOINWOODS // 20210310.1 #1 Broken Object-Level Authorisation Example: Parler Parler.com servers Parler App https://medium.com/swlh/exposing-the-riot-parler-api-mistakes-9a4db4e905d5 https://github.com/d0nk/parler-tricks https://github.com/daniel-centore/ParlerScraper authorisation point attacker (@donk_enby) no authorisation needed authentication point api.parler.com/v2/login/new Exploitability 3 Prevalence 3 Detectability 2 Technical 3
  • 23.
    27 27 © 2021 EOINWOODS // 20210310.1 #2 Broken User Authentication Exploitability 3 Prevalence 2 Detectability 2 Technical 2 • A range of possible problems rather than a single weakness • Allowing “credential stuffing” • Accepting weak passwords => brute-force credential attacks • Revealing authentication information in the API structure (e.g. URL) • Missing or incorrect validation of authentication tokens (e.g. JWT) • Mistakes in protocol implementation (very easy to do !) • Example: see example #10
  • 24.
    28 28 © 2021 EOINWOODS // 20210310.1 #2 Broken User Authentication Exploitability 3 Prevalence 2 Detectability 2 Technical 2 • Mitigations: • Multi-factor authentication for humans • Controls around login & credential recovery (e.g. password rules, lockout periods after failures, captchas, rate limiting) • Use proven, tested authentication mechanisms • Take time to understand any sophisticated security technologies • Careful implementation with expert design and code review • Functional and penetration testing
  • 25.
    29 29 © 2021 EOINWOODS // 20210310.1 #3 Excessive Data Exposure Exploitability 3 Prevalence 2 Detectability 2 Technical 2 • APIs often return more data that is required by the client • client-side filtering hides this from the user but not from software • API developers don’t always know what the client needs • or are trying to provide a more general solution to avoid rework • Sometimes an assumption that the client is ”trusted” • analogous problem to browser-side security in webapps • Problem often not obvious unless you know the data • automated tools aren’t going to spot this
  • 26.
    30 30 © 2021 EOINWOODS // 20210310.1 #3 Excessive Data Exposure Exploitability 3 Prevalence 2 Detectability 2 Technical 2 Example: Facebook Marketplace (2019) https://www.7elements.co.uk/resources/blog/facebooks-burglary-shopping-list/ "location": { "latitude": 54.9942235, "longitude": -1.6041244, "reverse_geocode": { "city": ”Newcastle upon Tyne", "state": ”England", "postal_code": "" }, "reverse_geocode_detailed": { "city": ”Newcastle upon Tyne", "state": ”England", "postal_code": ”NE2 2DS" } }
  • 27.
    31 31 © 2021 EOINWOODS // 20210310.1 #3 Excessive Data Exposure Exploitability 3 Prevalence 2 Detectability 2 Technical 2 • Mitigations • Assume the client is untrusted when developing an API • Always use the ”need to know” principle when designing data types • needs understanding of the context of the API request § Don’t return serialised forms of internal types • can leak information over time • use specifically designed return types with the right data items § Identify sensitive information classes (e.g. PII, card data, …) and have a specific review of any API call that accesses this information
  • 28.
    32 32 © 2021 EOINWOODS // 20210310.1 #4 Resources and Rate Limiting Exploitability 2 Prevalence 3 Detectability 3 Technical 2 • Classical DoS attacks use network protocols (e.g. SYN flood) • APIs are also vulnerable to overload attacks • can be exacerbated by the right (excessive) parameter values • e.g. parallel upload of multi-GB binary files • Two dimensions • Number of parallel requests allowed • Quantity of resources each request can be allocated • Mitigations: • Rate limiting at API level (spike limit, limit in time interval) • Rate limiting at session or user level (ditto) • Hard limits on parameter values and sizes • Runtime limits on memory, CPU, file descriptors, …
  • 29.
    33 33 © 2021 EOINWOODS // 20210310.1 #4 Resources and Rate Limiting Exploitability 2 Prevalence 3 Detectability 3 Technical 2 $> wget https://svc.com/inv/item?name=%22%2a%22&maxsize=9999999 • Hopefully this gets stopped immediately by a validation check • Or overridden within the API by an internal maximum • Unfortunately, quite a few APIs don’t always do this • Result is likely to be a large database result set and a huge amount of memory used => a runtime failure
  • 30.
    34 34 © 2021 EOINWOODS // 20210310.1 #5 Broken Function-Level Authorisation Exploitability 3 Prevalence 2 Detectability 1 Technical 2 • Incomplete or incorrect authorisation checks when API called • like #1 (object-level authorisation) a range of possible problems • Rarely totally missing, usually “holes” in the implementation • Frequently a result of a complex security model or API design • “correct” is complex, given interaction of authentication, roles, sensitivity levels, … • Can be due to complexity of application or 3rd party component • e.g. declarative security rules can often contain subtle problems • e.g. “falling through” logic which ends up providing access by mistake
  • 31.
    35 35 © 2021 EOINWOODS // 20210310.1 #5 Broken Function-Level Authorisation Exploitability 3 Prevalence 2 Detectability 1 Technical 2 Example: NewRelic “delete filterset” vulnerability To create a NR “filter set” you call POST https://infrastructure.newrelic.com/accounts/12345/settings/filterSets … passing a parameter block defining the new filter set. It turns out that calling … DELETE https://infrastructure.newrelic.com/accounts/12345/settings/filterSets … could delete the filter set without checking the user is authorised to do so https://www.cloudvector.com/owasp-api-security-top-10- broken-function-level-authorization/
  • 32.
    36 36 © 2021 EOINWOODS // 20210310.1 #5 Broken Function-Level Authorisation Exploitability 3 Prevalence 2 Detectability 1 Technical 2 • Mitigations • Simple as possible in design and implementation • Highlight sensitive operations for specific review • Thorough automated functional testing of authorisation • Take time to understand sophisticated security technology • Don’t invent your own security technology (again) • Always default to “no access”
  • 33.
    38 38 © 2021 EOINWOODS // 20210310.1 #6 Mass Assignment Exploitability 2 Prevalence 2 Detectability 2 Technical 2 • Different fields in a data entity often have different sensitivities • We often use libraries to “bind” data elements to and from API parameter sets • var item = JSON.parse(json_str); // JavaScript • // Java with Jackson Trade t = mapr.readObject(jsonStr, Trade.class); • Client could add “rogue” fields to overwrite sensitive state
  • 34.
    39 39 © 2021 EOINWOODS // 20210310.1 #6 Mass Assignment Example: the Harbor privilege escalation vulnerability Harbor: ”Our mission is to be the trusted cloud native repository for Kubernetes” Unfortunately, their product contained a privilege escalation vulnerability: POST /api/users HTTP/1.1 { “username”:”test”, ”email”:”test123@gmail.com”, ”realname”:”no name”, ”password”:”password1u0021″, ”comment”:null, “has_admin_role”:”true” } … due to a JSON mass assignment operation in JavaScript! https://unit42.paloaltonetworks.com/critical-vulnerability-in-harbor- enables-privilege-escalation-from-zero-to-admin-cve-2019-16097/ Exploitability 2 Prevalence 2 Detectability 2 Technical 2
  • 35.
    40 40 © 2021 EOINWOODS // 20210310.1 #6 Mass Assignment - Example Simple filtering example: function filterProperties(propList, obj) { for (var p in obj) { if (!obj.hasOwnProperty(p)) continue ; if (propList.indexOf(p) === -1) { delete obj[p]; } } } var fieldList = [‘name’, ‘cpid’, ‘price’, // … ]; filterProperties(fieldList, accountItem) { name: ‘My Customer', cpid: '1234234', price: 12.54, agentNotes: 'ZnVuY3Rpb24gZmlsdGVyUHJvcGVy dGllcyhwcm9wTGlzdCwgb2JqKSB7C iAgZm9yICh2YXIgcCBpbiBvYmopIH sKICAgIGlmICghb2JqLmhhc093blB yb3BlcnR5KHApKSBjb250aW51ZTsK ICAgIGlmIChwcm9wTGlzdC5pbmRle E9mKHApID09PSAtMSkgewogICAgIC BkZWxldGUgb2JqW3BdOwogICAgfQo gIH0KfQ==' } { name: ‘My Customer', cpid: '1234234', price: 12.54, }
  • 36.
    41 41 © 2021 EOINWOODS // 20210310.1 #6 Mass Assignment Exploitability 2 Prevalence 2 Detectability 2 Technical 2 • Mitigation: • Be careful when using automatic data binding libraries • Use specific types for API definition and explicit code to extract values and apply them to system state • Have ”whitelists” for fields that can be updated by a client
  • 37.
    42 42 © 2021 EOINWOODS // 20210310.1 #7 Security Misconfiguration Exploitability 3 Prevalence 3 Detectability 3 Technical 2 • Again a class of problem rather than a single cause • Missing security patches • Incorrect authorisation configuration • Unnecessary features enabled • Security enforcement (e.g. requiring TLS) incorrect or missing • Exposing sensitive information (e.g. 500 error stack traces!) • Mitigation • Testing (automated security tests, manual penetration testing) • Automated configuration and deployment for consistency • Expert review and code scanning throughout projects • Careful error handling
  • 38.
    43 43 © 2021 EOINWOODS // 20210310.1 #7 Security Misconfiguration Exploitability 3 Prevalence 3 Detectability 3 Technical 2 Example: Algolia Search $> curl https://myappid-dsn.algolia.net/1/keys/APIKEY?x-algolia- application-id=myappid&x-algolia-api-key=a7hw7gsh273hrk382 { ”value”: ‘.....’, “createdAt”: 15173453234, “acl” : [“search”, “addObject”, … ”editSettings”, “listIndexes”, …] } It turns out that many people accidentally use their admin API key for client API calls because of the way that Algolia’s documentation is written. https://www.secjuice.com/api-misconfiguration-data-breach
  • 39.
    44 44 © 2021 EOINWOODS // 20210310.1 #7 Security Misconfiguration Exploitability 3 Prevalence 3 Detectability 3 Technical 2 Example: Capital One https://krebsonsecurity.com/tag/capital-one-breach Capital One VPC M o d S e c u r i t y AWS S3 Bucket AWS EC2 VM $ > a w s i a m l i s t - r o l e s $ > … P E % { R E Q B O D Y _ P R O C E S S O R _ E R R O R } , B Q % { M U L T I P A R T _ B O U N D A R Y _ Q U O T E D } , B W % { M U L T I P A R T _ B O U N D A R Y _ W H I T E S P A C E } , D B % { M U L T I P A R T _ D A T A _ B E F O R E } , D A % { M U L T I P A R T _ D A T A _ A F T E R } , H F % { M U L T I P A R T _ H E A D E R _ F O L D I N G } , L F % { M U L T I P A R T _ L F _ L I N E } , M o d S e c u r i t y C o n f i g u r a t i o n • M i s t a k e i n M o d S e c u r i t y a l l o w e d a t t a c k e r i n t o V M • I A M m i s c o n f i g u r a t i o n a l l o w e d a c c e s s t o S 3 # ModSecurity (default) configuration SecRuleEngine DetectionOnly SecRequestBodyAccess On SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap+|/)|text/)xml" "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML" SecRule REQUEST_HEADERS:Content-Type "application/json" "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON" SecRequestBodyLimit 13107200 SecRequestBodyNoFilesLimit 131072 SecRequestBodyLimitAction Reject SecRule REQBODY_ERROR "!@eq 0" "id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.’, logdata:'%{reqbody_error_msg}',severity:2" SecRule MULTIPART_STRICT_ERROR "!@eq 0" "id:'200003',phase:2,t:none,log,deny,status:400, msg:'Multipart request body failed strict validation: PE %{REQBODY_PROCESSOR_ERROR}, BQ %{MULTIPART_BOUNDARY_QUOTED}, BW %{MULTIPART_BOUNDARY_WHITESPACE}, DB %{MULTIPART_DATA_BEFORE}, DA %{MULTIPART_DATA_AFTER}, HF %{MULTIPART_HEADER_FOLDING}, LF %{MULTIPART_LF_LINE}, SM %{MULTIPART_MISSING_SEMICOLON}, IQ %{MULTIPART_INVALID_QUOTING}, IP %{MULTIPART_INVALID_PART}, IH %{MULTIPART_INVALID_HEADER_FOLDING}, FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'" SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'" SecPcreMatchLimit 1000 SecPcreMatchLimitRecursion 1000 SecRule TX:/^MSC_/ "!@streq 0" "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
  • 40.
    45 45 © 2021 EOINWOODS // 20210310.1 #8 Injection Exploitability 3 Prevalence 2 Detectability 3 Technical 3 • Our old friend from the Webapp Top 10! • Dangerous in APIs as well as in webapps • Anything interpreted can be injected: • Database query parameters • Command line arguments • Configuration items that are parsed and processed
  • 41.
    46 46 © 2021 EOINWOODS // 20210310.1 #8 Injection Exploitability 3 Prevalence 2 Detectability 3 Technical 3 Example: check parameters and avoid direct SQL String tradeId = req.path().param(“tradeid”); ESAPI.validator().getValidInput(“tradeId”, tradeId, “HTTPParameterValue”, 12, false, true); String query = “select id, ccy, value, … from trade where id=?” ; PreparedStatement ps = conn.prepareStatement(query); ps.setString(1, tradeId); ResultSet results = ps.executeQuery() ;
  • 42.
    47 47 © 2021 EOINWOODS // 20210310.1 #8 Injection Exploitability 3 Prevalence 2 Detectability 3 Technical 3 • Mitigation: • Validate and sanitise all data entering the system • Use a single, well-tested, validation library to make validation reliable and straightforward (“easy thing” == “what is actually done”) • Where possible use APIs rather than interpreters (e.g. bind parameters for “prepared” database queries not query strings) • Sanity check result payloads (e.g. maximum size checks) • Strongly type API interfaces and enforce types strictly
  • 43.
    48 48 © 2021 EOINWOODS // 20210310.1 #9 Improper Asset Management Exploitability 3 Prevalence 3 Detectability 2 Technical 2 • Many application estates today are not well understood • Old applications can run for years with little attention • Will contain vulnerabilities in old software components • Often skipped during software security remediation work • Can have deliberate or accidental vulnerabilities themselves • Compromises may not be noticed • Sometimes important applications have old neglected features • Old data interfaces left in place for backwards compatibility • Unsupported opensource components to avoid regression testing • Insecure mechanisms (e.g. FTP file transfer) to avoid touching other old applications
  • 44.
    49 49 © 2021 EOINWOODS // 20210310.1 #9 Improper Asset Management Exploitability 3 Prevalence 3 Detectability 2 Technical 2 • New applications can also introduce problems if not understood • Microservices introduce many moving parts with network interfaces • Cloud allows application teams to deploy new applications and infrastructure quickly and independently … and perhaps insecurely • Rate of change in modern application estates can make keeping track of the estate difficult if not automated … tomorrow’s legacy
  • 45.
    50 50 © 2021 EOINWOODS // 20210310.1 #9 Improper Asset Management Exploitability 3 Prevalence 3 Detectability 2 Technical 2 Example: application evolution Monolithic Core «REST» Microservice 1 «REST» Microservice 2 «REST» «JSON/JMS» «XML/MQ» «SOAP/HTTP» Today’s main interfaces Yesterday’s legacy
  • 46.
    © 2021 EOINWOODS // 20210101.1 #9 Improper Asset Management Example: the scale problem Large organisations have thousands of applications, servers, services, message queues, databases, … … all constantly changing Exploitability 3 Prevalence 3 Detectability 2 Technical 2
  • 47.
    52 52 © 2021 EOINWOODS // 20210310.1 #9 Improper Asset Management Exploitability 3 Prevalence 3 Detectability 2 Technical 2 • Mitigation: • There are no easy mitigations once in this situation! • Easy to say, but avoidance is the most effective mitigation • Finding these applications and features is often the most difficult part • Network scanning can be useful to find unexpected end points • Once found, investing in modernisation, improving security or retirement are all options • Automate maintenance of application and infrastructure inventories wherever possible
  • 48.
    53 53 © 2021 EOINWOODS // 20210310.1 #10 Insufficient Logging & Monitoring Exploitability 2 Prevalence 3 Detectability 1 Technical 2 • Another familiar “friend” from the Webapp Top 10 • Logging and monitoring rarely comes ”for free” with APIs • therefore it often gets forgotten or deprioritised • Poor logging and monitoring technology, implementation or practices means it is difficult to detect and respond to suspicious activity • e.g. you find that an API credential has been compromised for several days … do you know what that credential has been used for while compromised?
  • 49.
    54 54 © 2021 EOINWOODS // 20210310.1 #10 Insufficient Logging & Monitoring Exploitability 2 Prevalence 3 Detectability 1 Technical 2 • Example: the need for monitoring Webapp automated credential stuffing attack database access through injection attack exfiltration of bulk data Monitoring could alert to all three aspects of the attack: • login failure monitoring • excessive database result set • unusual large outbound transfer
  • 50.
    55 55 © 2021 EOINWOODS // 20210310.1 #10 Insufficient Logging & Monitoring Exploitability 2 Prevalence 3 Detectability 1 Technical 2 • Mitigation … all well known solutions • Log all security sensitive events (authentication activity, access failures, validation failures, …) • Keep logs accessible but secure • Use SEIM systems to aggregate the logs from different sources • Build awareness of ”normal” and create dashboards for security related metrics to allow ”abnormal” to be spotted
  • 51.
    © 2021 EOINWOODS // 20210101.1 Summary of Vulnerability Types • Injection • SQL, configuration, operating system command, … • Inadequate validation • Of authentication to confirm identity of caller • Of authorisation to access resources • Accepting unexpected inputs (e.g. unnecessary fields, excessive parameter lengths) • Implementation mistakes • Returning too much data • Incomplete or faulty authorisation checks • Blindly binding data structures to inputs • Environment problems • Need for rate limiting • Monitoring and logging • Careful configuration of the entire stack
  • 52.
  • 53.
    59 59 © 2021 EOINWOODS // 20210310.1 Security Awareness Security Design Secure Implementation Security Testing Some Key Aspects of Software Security for Teams Entire team Security requirements Threat modelling Security design Secure design Secure implementation Functional security tests Code reviews SCA Static analysis Dynamic testing (DAST) Penetration testing
  • 54.
    60 60 © 2021 EOINWOODS // 20210310.1 Securing an API API FUNCTIONS A U T H O R I S A T I O N ( A C C E S S C O N T R O L ) A U D I T I N G A U T H E N T I C A T I O N R A T E L I M I T I N G Volume Identity Records Access
  • 55.
    61 61 © 2021 EOINWOODS // 20210310.1 auth code Over TLS A W S A P I G a t e w a y rate limiting A P I F u n c t i o n Securing an API - Example AWS Java + Spring process A u d i t L o g g i n g F i l t e r AWS Cloud Watch centralised logging A u t h o r i s a t i o n P r o x y application authorisation check API Client Okta OAuth2 Service (Authentication & Authorization Service) login for auth code A u t h e n t i c a t i o n F i l t e r authenticate w/auth code to get access token A u t h o r i s a t i o n F i l t e r API access check via token
  • 56.
    62 62 © 2021 EOINWOODS // 20210310.1 Lots of Choice When Securing an API A u t h e n t i c a t i o n & A u t h o r i s a t i o n Local implementation (users, passwords, groups, ACLs) Cloud services (AWS Cognito, Azure AD, …) 3rd party services (Auth0, Okta, …) Enterprise products (IAM vendors) Open source (Keycloak, Gluu, …) A u d i t i n g Plain files OS logging Database records Cloud services (CloudWatch, Azure Monitor) SIEM (Splunk, Rapid 7, …) R a t e L i m i t i n g Cloud API gateways Enterprise API gateways Reverse proxies Open source middleware
  • 57.
    © 2021 EOINWOODS // 20210101.1 Key Tactics • Don’t trust clients • authentication, authorisation, validation • Identify “interpreters” and sanitise inputs, use bind variables, … • command lines, database queries, configuration data, … • Protect valuable information at rest and in transit • encryption • Simplicity • Avoid the special cases, make sure the system is understood • Standardise and Automate • consistency, correctness, avoid configuration errors
  • 58.
    © 2021 EOINWOODS // 20210101.1 Tactic: Don’t Trust Clients • Be wary of everything sent by a client • Assume possible tampering • TLS connections • short lived sessions • reauthenticate humans, recheck tokens before sensitive operations • use opaque tokens for IDs • validate everything
  • 59.
    © 2021 EOINWOODS // 20210101.1 Tactic: Watch Out for Injection • Many things are interpreters • Operating system shells • Database query languages • Configuration files • Parsers • Assume someone will notice! • Avoid using direct string manipulation • libraries and bind variables • Sanitise strings passed to interpreters • 3rd party library (e.g. OWASP) • Reject very long strings
  • 60.
    © 2021 EOINWOODS // 20210101.1 Tactic: Protect Information • Assume perimeter breach • defence in depth • encrypt everything possible • But there are tradeoffs • slows everything down • querying is difficult • Message routing on sensitive fields • Manage and rotate keys • Complexity added to restore
  • 61.
    © 2021 EOINWOODS // 20210101.1 Tactic: Simplify and Standardise • Complexity is the enemy of security • “you can’t secure what you don’t understand” • special cases often forgotten • Simplify, standardise, automate • Simple things easier to check & secure • Standardisation removes a lot of special cases • Automation removes human inconsistencies avoiding one area of risk
  • 62.
    © 2021 EOINWOODS // 20210101.1 A Few Words on Tools • Security tools are obviously useful • Many types exist from simple to very complex • Need make sure people don’t view tools as an alternative to thinking! • Main groups • Specialist security scanning tools • Interactive tools for penetration and exploratory testing • Software composition analysis (open source scanning)
  • 63.
    © 2021 EOINWOODS // 20210101.1 Automated Security Testing • Automated tools are useful for some types of security problem • SAST – static scanning • DAST – simulated attacks • IAST – agent-based monitoring • RASP – runtime security monitoring • Challenges are false positives and effort to mitigate if used late • Danger of over-reliance
  • 64.
    © 2021 EOINWOODS // 20210101.1 Postman • API development & testing suite • Popular for functional and security API testing • Desktop tool with link to cloud service (with a web UI) • Interactive or command line (via ”Newman” runner extension) https://www.postman.com/
  • 65.
    © 2021 EOINWOODS // 20210101.1 BurpSuite • Proxy, scanning, pentest tool • Very capable free version • Fuller commercial version available • Inspect traffic, manipulate headers and content, replay, spider, … • Made in Knutsford! http://portswigger.net/burp
  • 66.
    © 2021 EOINWOODS // 20210101.1 Metasploit • The pentester’s ”standard” tool • Very wide range of capabilities • Commercial version available https://www.metasploit.com HTTPS://WWW.METASPLOIT.COM
  • 67.
    © 2021 EOINWOODS // 20210101.1 Open Source Scanning • Example commercial tools for OSS security, audit & compliance: • BlackDuck • Whitesource • Sonatype LCM • Snyk • Scan builds identifying open source • Checks for known vulnerabilities • Alerts and dashboards for monitoring www.blackduck.com www.whitesourcesoftware.com www.sonatype.com/nexus-lifecycle www.snyk.io
  • 68.
  • 69.
    © 2021 EOINWOODS // 20210101.1 OWASP API Top 10 - 2019 #1 Broken Object Authorization #2 Broken User Authentication #3 Excessive Data Exposure #4 Resources & Rate Limiting #5 Broken Function Authorization #6 Mass Assignment #7 Security Misconfiguration #8 Injection #9 Improper Asset Management #10 Insufficient Logging and Monitoring SOME MAY LOOK “OBVIOUS” BUT APPEAR ON THE LIST YEAR AFTER YEAR, BASED ON REAL VULNERABILITY DATA!
  • 70.
    77 77 © 2021 EOINWOODS // 20210310.1 Key Aspects of API Security Preventing Injection • SQL, configuration, commands, ... Validation • inputs, outputs, authentication, authorisation Implementation • automatic binding, too much data, faulty checking Environment • rate limiting, monitoring, logging, configuration
  • 71.
    78 78 © 2021 EOINWOODS // 20210310.1 Elements of Securing an API API Function Authorisation Authentication Rate Limiting Auditing
  • 72.
    79 79 © 2021 EOINWOODS // 20210310.1 Useful Tactics for API Security Don’t trust clients Watch out for injection Protect information Simplify and standardise
  • 73.
    80 80 © 2021 EOINWOODS // 20210310.1 Books