Embed Size (px)
Citation preview
AppSec 101Eivind Arvesen
Bouvet
AppSec 101Eivind Arvesen
Bouvet
Outline
o Introductiono Motivationo Most critical web application security riskso Resources
Be problem-oriented
Introduction 🖐
Who am I?
o Eivind Arvesen, M.Sc.o Bouvet since summer 2017o Consultant
o Developero Architect
o Leader in subject groups:o Securityo Agile (Lean and DevOps)
Who am I?
o Hobby-writer and -arguer💩
Security 🔐
Security
Information Security (InfoSec)Protecting information, hardware software and privacy against people, accidents and programs.
Security
Application Security (AppSec)Developing, adding and testing security features in applications in order to avoid security risks.
Motivation 🏁
Why do we care?
o Software is (still) eating the worldo Major criseso Can become huge problems for userso Laws and regulations (compliance)
o GDPRo Good craftmanship
Why do we care?
o Democratization of tools (and information)o … even kids can do it –
and they do!o Examples in Norge
Typical Vulnerabilities 💻
OWASP
The Open Web Application Security Project
Community-driven non-profit produces freely available resources such as:• Articles• Methodologies• Documentation• Tools• Technologies
«The Ten Most Critical Web Application Security Risks.»
OWASP Top-10 (2017)
OWASP Top-10 (2017)
1. Injection2. Broken Authentication 3. Sensitive Data Exposure4. XML External Entities (XXE)5. Broken Access Control6. Security Misconfiguration7. Cross-Site Scripting (XSS)8. Insecure Deserialization9. Using Components with Known Vulnerabilities10.Insufficient Logging & Monitoring
1. Injection«Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a
command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing
data without proper authorization.»
Example: SQL-query using untrusted data
String query = "SELECT * FROM accounts WHERE customerID = '" + request.getParameter("id") + "'";
1. Injection
http://example.com/app/accountView?id=’or’1’=’1
… returns all rows of the table in question
1. Injection
1. Injection
Prevention:o Use a safe API (avoiding the use of the
interpreter), parameterized queries, Object Relational Mapping Tools (ORMs), etc.
o White list input validation (server-side).o Character-escaping for any residual dynamic
queries, using interpreter-specific escape syntax.
o Use LIMIT and similar controls to avoid mass disclosure of records in case of SQL injection.
1. Injection
2. Broken Authentication«Application functions related to authentication and session
management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or
to exploit other implementation flaws to assume other users’ identities temporarily or permanently.»
Examples:o Permits automated attacks, such as credential stuffingo Permits brute force attackso Permits default, weak, or well-known passwords, such as "Password1" or
"admin/admin“o Uses weak or ineffective credential recovery and forgot-password
processeso Uses plain text, encrypted, or weakly hashed passwordso Has missing or ineffective multi-factor authenticationo Exposes Session IDs in the URLo Does not rotate Session IDs after successful logino Does not properly invalidate Session ID during logout or when inactive
2. Broken Authentication
2. Broken Authentication
2. Broken Authentication
Prevention:o Implement multi-factor authenticationo Don’t use default credentials (admin users in particular) o Implement weak-password checks (matche against known
weak or compromised ones)o Align password length, complexity and rotation policies with
modern evidence-based policieso Harden registration, credential recovery, and API pathways
against account enumeration by using same message for all outcomes
o Limit (or increasingly delay) failed login attempts; Log failures and alert admins when attacks are detected
o Use proper (server-side) session-handling management
2. Broken Authentication
3. Sensitive Data Exposure«Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or
modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.»
3. Sensitive Data Exposure
Examples of sensitive data:o Passwordso Credit card informationo Credentialso Personnummero Health recordso Personally Identifiable
Informationo Other personal information
3. Sensitive Data Exposure
3. Sensitive Data Exposure
Prevention:o Identify and classify your datao Don’t store date you don’t needo Encrypt all sensitive data «at rest» / in storageo Encrypt all traffic «in transit» / on the wireo Use strong algorithms, protocols, and keys – handle these
safelyo Don’t cache responses that contain sensitive datao Store passwords using strong, salted hashing with a «work-
factor» (delay factor)
3. Sensitive Data Exposure
4. XML External Entities (XXE)«Many older or poorly configured XML processors evaluate external entity references within XML documents. External
entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code
execution, and denial of service attacks.»
4. XML External Entities (XXE)
Example: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>
4. XML External Entities (XXE)
Prevention:o Use less complex data formats (JSON?), if possible; avoid
serialization of sensitive datao Patch/upgrade all XML-processors and -libraries; Update
SOAP to >= 1.2o Disable XXE and DTD-processing in XML-parserso Implement whitelisting (server-side) validation, sanitation or
filtering to prevent hostile datao Verify that XML/XSL uploads are validated using XSD or
similar
5. Broken Access Control«Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users’
data, change access rights, etc.»
Examples of access:o Access to admin panelo Access to server via FTP / SFTP / SSHo Access to other applications on servero Access to database
5. Broken Access Control
5. Broken Access Control
Example:
http://example.com/app/accountInfo?acct=myacct
http://example.com/app/accountInfo?acct=notmyacct
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
Prevention:o Deny access by default, unless it’s a public resourceo Implement control mechanisms once and re-use them, including minimizing
CORSo Model access controls should enforce record ownership; users should only be
able to CRUD data that belongs to themo Enforce business limit requirements in domain modelso Disable web server directory listing; ensure file metadata and backups are not
presento Log access control failures, alert admins on repeated failures, etc.o Rate limit APIs and and control access (make automated attacks more difficult)o Invalidate JWT-tokens (server-side) after logout
5. Broken Access Control
Let’s take a breather 🌬
How Hacking Works
Back to Business 😈
6. Security Misconfiguration«Security misconfiguration is the most commonly seen issue. This is
commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be
securely configured, but they must be patched and upgraded in a timely fashion.»
6. Security Misconfiguration
Examples:o Application server comes with
sample applications that are not removed
o Directory listing is not disabledo Server configuration allows
detailed error messages (e.g. stack traces)
o Public-by-default cloud service provider storage permissions
6. Security Misconfiguration
Many possible sources of error…o Networko Platformo Web servero Application servero Databaseo Frameworko Custom kodeo Pre-installed Virtual Machineso Containerso Storage
6. Security Misconfiguration
Prevention:o Implement a repeatable hardening
process, e.g. a reproducible, locked down environment
o A minimal platform without components you don’t use; remove unused features and frameworks
o Review and update configs appropriate to all security notes, updates and patches
o Segmented architecture, providing separation between components or tenants
o Implementing Security Headerso Automated verification of configurations
«Layered security»
7. Cross-Site Scripting (XSS)«XSS flaws occur whenever an application includes untrusted data
in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API
that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user
sessions, deface web sites, or redirect the user to malicious sites.»
7. Cross-Site Scripting (XSS)
Examples:o Reflected XSS
o App or API includes unvalidated/unescaped user input as part of (HTML) output
o Stored XSSo App or API stores unsanitized user input
that is viewed later by another user/admino DOM XSS
o SPA or API dynamically includes attacker-controllable data in DOM (via unsafe JS-APIs)
7. Cross-Site Scripting (XSS)
Prevention:o Use frameworks that escape XSS – but know their limits!o Escape untrusted HTTP request data based on the
context in the HTML output (body, attribute, JS, CSS, or URL)
o Applying context-sensitive encoding when modifying the browser document on the client side; otherwise apply context sensitive escaping techniques to browser APIs
o Enabling Content Security Policy (CSP) mitigates all but local file include-based XSS
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization«Insecure deserialization often leads to remote code execution.
Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay
attacks, injection attacks, and privilege escalation attacks.»
8. Insecure Deserialization
Explained:o Sending a bytestring-
representation of data/code back and forth between server and client
Illustrasjon: Wikimedia Commons
8. Insecure Deserialization
Example:o User logs in to a PHP-based site, which sets user state in a
«super-token»(client-side)a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:»b6a8b3bea87fe0e05022f8f3c88bc960";}
o Attacker changes role from «user» to «admin»a:4:{i:0;i:1;i:1;s:5:»Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
8. Insecure Deserialization
Prevention:o Don’t use serialized objects (from untrusted sources) if you can help ito Implement integrity checks (e.g. signatures) on all serialized objectso Enforce strict type constraints during deserialization (before object
creation)o Isolating and running code that deserializes in low privilege environments o Log all deserialization-related exceptions and failureso Restrict and monitor network connectivity from containers or servers that
deserialize o Monitoring deserialization, alerting if a user deserializes constantly
9. Using Components with Known Vulnerabilities
«Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a
vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using
components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.»
9. Using Components with Known Vulnerabilities
Examples:o Not knowing the versions of your
dependencies (and their dependencies)o Vulnerable, unsupported or out of date
software, e.g. OSes, web servers, databases, APIs, libraries
o Not scanning for vulnerabilitieso Not fixing or upgrading the underlying
platform, frameworks and dependencies (typically under slow change-control)
o Not testing compatibility of updated, upgraded, or patched libraries
o Not securing component configurations
9. Using Components with Known Vulnerabilities
Prevention:o Remove unused dependencies,
unnecessary features, components, files, and documentation
o Inventory all components and their dependencieso Versions, DependencyCheck, retire.js,
Snyko Cross-reference CVE and NVD
o Only obtain components from official sources over secure links; Use signed packages
o Monitor for unmaintained libraries
10. Insufficient Logging & Monitoring
«Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to
further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.»
10. Insufficient Logging & Monitoring
Example:o An attacker uses scans for users using a common password.
They can take over all accounts using this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.
o Since there is no logging, no one sees any warning signs, and can’t follow up on the ongoing attack.
10. Insufficient Logging & Monitoring
Prevention:o Ensure all login, access control failures, and
server-side input validation errors are logged (with sufficient context) and held for sufficient time
o Log in a format that can be consumed by a centralized log management solution
o Ensure high-value transactions have an audit trail with integrity controls (append-only DB)
o Establish monitoring and alerting, so that suspicious activities are detected and responded to
o Establish or adopt an incident response and recovery plan
(Bonus) 🎰
«Latest» from Vegas
Outlook authentication bypass
o Possible to avoid authentication via unsigned JSON Web Token
o Get any user’s email on Outlook Web under «new UI»
HTTP Request Smuggling (HTTP Desync Attack)
o Splice into somebody else’s request!
Illustration: PortSwigger
HTTP Request Smuggling (HTTP Desync Attack)
Illustration: PortSwigger
Adventures In Smart Buttplug Penetration (testing)
Illustration: smea's DEF CON-presentation
Adventures In Smart Buttplug Penetration (testing)
Illustration: smea's DEF CON-presentation
Adventures In Smart Buttplug Penetration (testing)
Illustration: smea's DEF CON-presentation
Adventures In Smart Buttplug Penetration (testing)
Illustration: smea's DEF CON-presentation
Adventures In Smart Buttplug Penetration (testing)
Illustration: smea's DEF CON-presentation
Adventures In Smart Buttplug Penetration (testing)
o Usual state of security (or lack thereof) in IoT…
o Inject code on a remote client (PC) from a malicious buttplug!
Internet of Shit™
Wanna learn more? 👩💻👨💻
Resources
o Top 10o Proactive Controls o Application Security
Verification Standard (ASVS)o Code Review Guideo Software Assurance Maturity
Model (SAMM)o Testing Projecto CVE / NVD
Tools
o Have I Been Pwnedo OWASP Dependency Checko SonarQubeo JFrog Xrayo Snyko Qualyso OWASP ZAPo Burp Suite
Practice
o OWASPo Webgoato Juiceshop
o CTFso Pico CTFo pwnable.kro OverTheWireo SmashTheStacko TG Hacko HackTheBox
Thanks! 👾
