The document discusses the OWASP Top 10 application security risks. It provides an overview of OWASP, an organization dedicated to enabling trustworthy software, and then summarizes each of the Top 10 risks: injection, broken authentication, sensitive data exposure, XML external entities, broken access control, security misconfiguration, cross-site scripting, insecure deserialization, using vulnerable components, and insufficient logging and monitoring. For each risk, it outlines symptoms and provides security advice on prevention and mitigation.

1. OWASP
Case Study: First-Security Mindset, Top Ten ASR

2. Kamil Piętka
kamil.p@devpark.pl

3. #OWASP
 OWASP - overview
 Top 10 Application Security Risks

4. #OWASP - OVERVIEW
The Open Web Application Security Project (OWASP) is an open community dedicated to
enabling organizations to develop, purchase, and maintain applications and APIs that can
be trusted.
 Official Project’s Page: https://www.owasp.org
 December 1
st
2001 (since April 21, 2004 charitable organization in USA)
 Non-profit
 OWASP Top 10 (last updated 2017)
 Core Values: OPEN, INNOVATION, GLOBAL, INTEGRITY

5. #1 – Injection
Injection flaws, 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.
 SQL
 NoSQL
 OS
 LDAP

6. #1 Injection
 Avoid RAW QUERY
 Use Constraints to prevent mass influence (LIMIT)
 Always validate incoming data.
 Sanitize all incoming data before using it
 filter_var ($var, FILTER_VALIDATE_EMAIL)
 Escape all outgoing data before passing it to its final destination (blade)
 strip_tags
 htmlspecialchars
 htmlentities
 mysqli_real_escape_string
 escapeshellcmd

7. #2 – Broken Authentication and Session
Any application dealing with data faces the challenge of ensuring only the right parties ever
have access to the data.
 It could be user information.
 Customer banking details
 Shopping cart details
 Healthy sensitive information
 Tax details

8. #2 – Broken Authentication and Session
Every application have to implemented Session management and authentication user
 Laravel Auth
 Session Guard
 username/passport authentication
 Hashing Password (bcrypt, one way)
 Reset Password By Email
 Laravel Socialize (Third Party Authentication)
 Laravel Passport (Oauth 2)
 Define Scope
 Define Grants
 Issuing Access Token

9. #2 – Broken Authentication and Session
Security Advice
 Two-factor authentication (SMS, 2FA Google).
 Limit or increasingly delay failed login attempts.
 Communication over HTTPS
 Avoid Client-Side Sessions (cookie driver)
 Implement weak-password check (poor 10000 password)
 Use Argon2 (since PHP7.2, Laravel 5.6)

10. #3 – Sensitive Data Exposure (GDPR)
Sensitive data deserves extra protection such as encryption at rest or in transit, as well as
special precautions when exchanged with the browser.
 In-Cases
 Bad developer caution, sharing untrusted credentials, leaking outside
 One engineer for all
 External Breach
 Poor or misconfiguration the database server
 Weak protection server housing backup database
 Unnecessary Data Storage (Store Data is actually needed)
 Using Insecure Cryptography
 Avoid base64_decode

11. #3 – Sensitive Data Exposure (GDPR)
 Staff Management
 Credential Audits
 LDAP (VPN)
 Principal of Least Privilege
 Separation of Concerns
 Dispatching roles between team (develop, code review, deploy)
 Encryption Data
 Both in-transit and at rest
 Keeping Data in Cloud (ie. Amazon RDS encrypted instances use the industry standard
AES-256)
 No impact for application queries
 Never build your own cryptography (Laravel encryption).

12. #4 XML External Entities (XXE)
Symptoms
 Acceptance XML directly
 XML input containing a reference to an external entity is processed by a weakly
configured XML parser.
 Feeds: SOAP, RSS, SAML

13. #4 XML External Entities (XXE)
 Use JSON instead XML
 Update SOAP 1.2 or higher
 Disable XML external entity – libxml_disable_entity_loader (libxml2)
 Use server-side input validation, filtering, or sanitization
Security Advice

14. #5 Broken Access Control
 Restiction on what authenticated users are allowed to do.
 Laravel Authorization Solution (Gates and Policies)
 Gates

15. #5 Broken Access Control
 Policies

16. #6 Security Misconfiguration
 Symptoms
 Ship a rough prototype to production
 Improperly configured permissions on cloud services
 Unnecessary features are enabled and installed
 Expose the Error Renders for users
 Security Advices
 A repeatable process that makes it fast and easy to deploy another environment that is
properly locked down
 Keep Development, Staging and Production configurations as close as possible
(excluding credentials)
 A minimally required platform (stack tools)
 Gitignore for config files (.env)

17. #7 Cross-Site Scripting (XSS)
 XSS flaws occur whenever an application takes untrusted data and sends it to a web
browser without proper validation or escaping.
 hijack user sessions, deface web sites, redirect malicious sites.
 XSS Attacks
 Store XSS – insert malicious payload to DB
 Reflect XSS - unvalidated and unescaped user input. Executing malicious HMTL in the
victim’s browser by replaced the link in email.
 Security Advices
 Always validate input data
 Escaping data before presenting the user
 Sanitize user input before writing it to disk
 Use POST and PUT Method to persist data (CSRF)

18. #8 Insecure Deserialization
 Symptoms
 Modify application logic, change behavior application achieving by remote code
execution
 Typical data tampering attacks, (changing the data content).
 Source of serialized data
 Remote- and inter-process communication (RPC/IPC)
 Web services, Micro services,
 Message brokers (Pusher)
 Caching/Persistence
 Databases, cache servers, file systems
 HTTP cookies, HTML form parameters

19. #8 Insecure Deserialization
 Security Advices
 Only accept trusted data for deserialization
 Disable or explicitly whitelist the deserialization of classes.
 Log incoming requests for JSON deserialization to proactively detect and block
potential attacks
 Constraint privileges for deserialized code.
 Check signature
 Monitoring exceptions

20. #9 Using Components With Known Vulnerabilities
 Remove unused dependencies.
 Continuously inventory the versions of both client-side and server-side components
 Only obtain components from official sources over secure links.
 Use tool sensiolabs/security-checker

21. #10 Insufficient Logging & Monitoring
 Correct logging and monitoring system finds attackers before they’ve had the chance to
actually infiltrate the system
 Logging level (CSP – content security policy)
 Use native Monolog Tool for Laravel
 Log levels (DEBUG ... NOTICE ... EMERGENCY)
 Easy consumed format
 Easy using
 Log::info('An informational message.')
 logger('An informational message.')
 Advance configurable (drivers and channels) since 5.6
 single, slack, daily...

22. #10 TOP - history

23. Kamil Piętka
kamil.p@devpark.pl