OWASP Top 10 Proactive Controls 2016 - NorthEast PHP 2017

OWASP TOP 10 PROACTIVE CONTROLS
2016

ABOUT ME
PHILIPPE GAMACHE
HI I’M PHILIPPE
I’m a Developer Evangelist for kuzzle.io.
Long-time internet developer, author,
screen caster, podcaster and speaker. I’m
specializes in PHP, Symfony, Kuzzle,
security, code quality, performance, real
time and geolocation.
• Sécurité PHP 5 et MySQL 5
• OWASP Montreal
• PHP Quebec
• Table Top Game Developer
• Pen & Paper RPG Writer

PURPOSE OF THE PRESENTATION
• OWASP Top 10 Proactive Controls 2016
• 10 critical security areas that web developers must be aware
• https://www.owasp.org/index.php/OWASP_Proactive_Controls
• OWASP Top 10
• 10 Most Critical Web Application Security Risks
• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
WHY WE ARE TALKING ABOUT THIS?

OPEN WEB APPLICATION SECURITY PROJECT
• It is a 501c3 not-for-proﬁt and also registered in Europe as a worldwide
charitable organization.
• Focused on improving the security of software.
• Mission is to make application security visible, so that people and
organizations can make informed decisions about true application
security risks.
• Everyone is welcome to participate in OWASP and all materials are
available under free and open software licenses.
CORE MISSION

• A1 — Injection
• Injection ﬂaws, such as SQL, OS, XXE, and LDAP injection occurs 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.
• A2 — Broken Authentication and Session Management
• 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
ﬂaws to assume other users’ identities (temporarily or permanently).
TOP 10 APPLICATION SECURITY RISKS - 2017

• A3 — 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 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.
• A4 — Broken Access Control
• Restrictions on what authenticated users are allowed to do are 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.

• A5 — Security Misconfiguration
• Good security requires having a secure configuration defined and deployed for
the application, frameworks, application server, web server, database server,
platform, etc. Secure settings should be defined, implemented, and maintained,
as defaults are often insecure. Additionally, software should be kept up to date.
• A6 — 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 deserves extra protection such as encryption at rest or in transit,
as well as special precautions when exchanged with the browser.

• A7 — Insuﬃcient Attack Protection
• The majority of applications and APIs lack the basic ability to detect, prevent, and
respond to both manual and automated attacks. Attack protection goes far beyond
basic input validation and involves automatically detecting, logging, responding,
and even blocking exploit attempts. Application owners also need to be able to
deploy patches quickly to protect against attacks.
• A8 — Cross-Site Request Forgery (CSRF)
• A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request,
including the victim’s session cookie and any other automatically included
authentication information, to a vulnerable web application. Such an attack allows
the attacker to force a victim’s browser to generate requests the vulnerable
application thinks are legitimate requests from the victim.

• A9 — 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.
• A10 — Underprotected APIs
• Modern applications often involve rich client applications and APIs, such as
JavaScript in the browser and mobile apps, that connect to an API of some
kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often
unprotected and contains numerous vulnerabilities.

VERIFY FOR SECURITY EARLY AND OFTEN
• Security testing is not made part of Software Development Life Cycle/
Agile.
• Carried out by others than the development team.
• Development team tries to ﬁx them without putting much thought from
coding and programming point of view.
PROBLEM STATEMENT

• Security must be integral part of SDLC/Agile.
• Include security while writing testing stories and tasks.
• Include the Proactive Controls in stubs and drivers.
• Security testing stories should be defined such that the lowest child story can be
implemented and accepted in a single iteration.
• Testing a Proactive Control must be lightweight.
• Consider OWASP Application Security Verification Standard (ASVS) as a guide to define
security requirements and testing.
• Convert scanning output into reusable Proactive Controls to avoid entire classes of
problems.
CONTROL EXPLAINED

• https://www.owasp.org/index.php/OWASP_Testing_Project
• https://www.owasp.org/index.php/
Category:OWASP_Application_Security_Verification_Standard_Project
• http://devops.com/2015/04/06/automated-security-testing-
continuous-delivery-pipeline/
• https://www.continuumsecurity.net/bdd-security/
• https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
• https://www.owasp.org/index.php/OWASP_OWTF
RESSOURCES

OWASP TOP 10 VULNERABILITY/ATTACKS
A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A9 - Using
Components with
Known
Vulnerabilities

PARAMETERIZE QUERIES
• Web application can be used to run dangerous OS commands;
• Against the OS hosting the database.
• SQL query and its parameters are contained in one query string.
PROBLEM STATEMENT

• Untrusted input should be prevented from being interpreted as part of
an SQL command:
• Use “Query Parameterization”;
• SQL statements are sent to and parsed by the database server
separately from any parameters.
CONTROL EXPLAINED

QUERY PARAMETERIZATION
$dbh =
new PDO("pgsql:host={$host};port={$port};dbname={$db};user={$user};password={$pass}");
$stmt = $dbh->prepare("update users set email=:new_email where id=:user_id");
$stmt->bindParam(':new_email', $email);
$stmt->bindParam(':user_id', $id);

• Use defense in depth;
• Use automated static analysis;
• Use proper database management system conﬁguration.
• Conﬁgure database engines to only support parameterized queries.
CONTROL EXPLAINED

• https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet
SQL_Injection_Prevention_Cheat_Sheet
• https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-
_Quick_Reference_Guide
RESSOURCES

A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A9 - Using
Components with
Known
Vulnerabilities

ENCODE DATA
PROBLEM STATEMENT
• Web forms written to accept inputs from untrusted sources/users.
• Attacker tricks users into executing malicious script that was not
originally built into the website.
• Manipulation of user response.
• XSS attacks execute in the user’s browser.
• Same risk remains in mobile based applications as well.

ENCODE DATA
CONTROL EXPLAINED
• Encoding is translating special characters into some equivalent form that is no
longer dangerous in the target interpreter.
• Manipulating user generated content:
• Ensure that data is ﬁltered;
• Ensure that data is encoded.
• Loading content from an external source:
• Apps that need to display untrusted content inside a Web View should use a
dedicated server/host to render and escape HTML/Javascript content in a safe
way. Prevents access to local system contents by malicious JavaScript code.

ENCODE DATA
• http://twig.sensiolabs.org/doc/filters/escape.html
• https://docs.zendframework.com/zend-escaper/theory-of-operation/
• https://laravel.com/docs/5.4/blade
• http://boldersecurity.github.io/encoder-comparison-reference/
• https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
• https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
RESSOURCES

ENCODE DATA
A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A9 - Using
Components with
Known
Vulnerabilities

VALIDATE ALL INPUTS
PROBLEM STATEMENT
• All the data directly entered by users should be treated as untrusted.
• An application should check that this data is both syntactically and
semantically valid (in that order) before using it in any way.
• The most secure applications treat all variables as untrusted and provide
security controls regardless of the source.

VALIDATE ALL INPUTS
CONTROL EXPLAINED
• Use two general approaches to performing input syntax validation white
listing preferred over black listing.
• Regular expressions oﬀer a way to check whether data matches a speciﬁc
pattern this is a great way to implement whitelist validation.
• The security of the application should be enforced where that input is used:
• If input is used to build an HTML response, then the appropriate HTML
encoding should be performed to prevent XSS attacks.
• If input is used to build a SQL statement, Query Parameterization should
be used.

VALIDATE ALL INPUTS
FILE UPLOAD
• Generic Upload Verification:
• Check filename;
• Check file size;
• Ensure decompressed size of file < maximum size;
• Ensure that an uploaded archive matches the type expected (zip, rar);
• Ensure structured uploads such as an add-on follow proper standard;
• And maybe check with an anti-virus.

VALIDATE ALL INPUTS
FILE UPLOAD
• Image Upload Veriﬁcation:
• Enforce proper image size limits;
• Use image rewriting libraries;
• Set the extension of the stored image to be a valid image extension;
• Ensure the detected content type of the image is safe.

VALIDATE ALL INPUTS
FILE UPLOAD
• If you can, check files on separate server.
• Beware of "special" files:
• "crossdomain.xml", "clientaccesspolicy.xml", "index.php", "config.yml",
".htaccess", "faveicon.ico", "composer.json"…
• Upload Storage:
• Use only trusted filenames + separate domain.

VALIDATE ALL INPUTS
VALIDATION AND SANITIZATION
<?php
$sanitized_email = filter_var($email, FILTER_SANITIZE_EMAIL);
if (filter_var($sanitized_email, FILTER_VALIDATE_EMAIL)) {
echo "This sanitized email address is considered valid.n";
}

VALIDATE ALL INPUTS
RESSOURCES
• http://htmlpurifier.org/
• http://www.bioinformatics.org/phplabware/internal_utilities/
htmLawed/
• https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet
• https://www.owasp.org/index.php/Testing_for_Input_Validation

VALIDATE ALL INPUTS
A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A9 - Using
Components with
Known
Vulnerabilities

IMPLEMENT IDENTITY AND AUTHENTICATION CONTROLS
PROBLEM STATEMENT
• Session management has to be secured in application ﬂow to maintain
the state of entity interacting with the server.
• Only authorized users must be accessing the resources after enough
authentication.

CONTROL EXPLAINED
• Do not limit the type of characters or length of user password within
reason;
• Limiting passwords to protect against injection is doomed to failure.
• Use proper encoder and other defenses described instead.
• Be wary of systems that allow unlimited password sizes.

CONTROL EXPLAINED
• Use Multi-Factor Authentication.
• Implement Secure Password Storage using cryptography controls.
• Implement Secure Password Recovery Mechanism.
• Session: Generation and Expiration: On any successful authentication and
reauthentication the software should generate a new session and session id.
• Mandatory to set expiration timeouts for every session, after a speciﬁed
period of inactivity.
• Reauthentication for Sensitive Features.

PASSWORD ENCODING
<?php
$cost = 15;
// From PHP 5.5 to 7.1 PASSWORD_DEFAULT to using the bcrypt algorithm
$password_hash = password_hash("secret_password", PASSWORD_DEFAULT, ["cost" => $cost] );

CONTROL EXPLAINED - MOBILE APPLICATION OR API
• Token Based Authentication.
• Avoid storing/persisting authentication credentials locally on the device.
• Perform initial authentication using the username and password supplied
by the user, and then generate a short-lived access token which can be
used to authenticate a client's request without sending the user’s
credentials.

RESSOURCES
• https://www.owasp.org/index.php/Authentication_Cheat_Sheet
• https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
• https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
• https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
Choosing_and_Using_Security_Questions_Cheat_Sheet
• https://www.owasp.org/index.php/Testing_for_authentication

A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A1A9 - Using
Components with
Known
Vulnerabilities

IMPLEMENT APPROPRIATE ACCESS CONTROLS
PROBLEM STATEMENT
• Access Control is one of the main areas of application security design that must be
heavily thought through up front, especially when addressing requirements like
multitenancy and horizontal (data speciﬁc) access control.
• Hard-coded role checks in application code:
• Lack of centralized access control logic;
• Untrusted data driving access control decisions;
• Access control that is "open by default";
• Lack of addressing horizontal access control in a standardized way (if at all);
• Access control logic that needs to be manually added to every endpoint in code;
• Access Control that is “sticky” per session;
• Access Control that requires per-user policy.

CONTROL EXPLAINED
• Force All Requests to go Through Access Control Checks.
• Deny by Default.
• Principle of Least Privilege: each user or system component should be allocated the
minimum privilege required to perform an action for the minimum amount of time.
• Avoid Hard Coded Access Control Checks: enforcement layer (checks in code) and your
access control decision-making process (the access control "engine") should be separated
when possible.
• Code to the Activity: Consider checking if the user has access to that feature in code, as
opposed checking what role the user is in code.
• Server side Trusted Data Should Drive Access Control. Policy data such as a user’s role or an
access control rule should never be part of the request.

CODE TO THE ACTIVITY
<?php
// Instead of hard-coding role check all throughout your code base
if ($user->hasRole("ADMIN")) || ($user->hasRole("MANAGER")) {
deleteAccount();
}
// Consider the following instead
if ($user->hasAccess("DELETE_ACCOUNT")) {
deleteAccount();
}

RESSOURCES
• https://www.owasp.org/index.php/Access_Control_Cheat_Sheet
• https://www.owasp.org/index.php/Testing_for_Authorization

A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A1A9 - Using
Components with
Known
Vulnerabilities

PROTECT DATA
PROBLEM STATEMENT
• Access Control is one of the main areas of application security design
that must be heavily thought through up front, especially when
addressing requirements like multitenancy and horizontal (data speciﬁc)
access control.

PROTECT DATA
CONTROL EXPLAINED
• Classify and Encrypt Data at rest.
• Develop your own crypto algorithm & key size should be optly chosen.

PROTECT DATA
CONTROL EXPLAINED
• Encrypt Data in Transit. TLS is by far the most common and widely
supported model used by web applications for encryption in transit:
• Conﬁdentiality: Spy cannot view your data;
• Integrity: Spy cannot change your data
• Authenticity: Server you are visiting is the right one.
• Implement Protection in Transit.

PROTECT DATA
RESSOURCES
Transport_Layer_Protection_Cheat_Sheet
• https://www.ssllabs.com/projects/best-practices/
• http://www.youtube.com/watch?v=zEV3HOuM_Vw
• https://whispersystems.org/blog/asynchronous-security/
• http://certificate-transparency.org

PROTECT DATA
RESSOURCES
• https://www.owasp.org/index.php/Pinning_Cheat_Sheet
• https://www.gitbook.com/book/jedisct1/libsodium/details
• https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
• https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
• https://www.owasp.org/index.php/Testing_for_Weak_SSL/
TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-
CRYPST-001)

PROTECT DATA
A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A1A9 - Using
Components with
Known
Vulnerabilities

IMPLEMENT LOGGING AND INTRUSION DETECTION
PROBLEM STATEMENT
• Logging is used in BIA, Monitoring, Forensics, compliance and intrusion
detection.
• It must be designed properly from early SDLC stage.

CONTROL EXPLAINED
• Ensure proper level of logging
• Follow a common logging approach within the system and across systems
where possible to make correlation easy
• Make sure to always log the timestamp and identifying information like
the source IP and userid, but be careful not to log private or conﬁdential
data or opt out data or secrets
• Design proper positioning of IDS sensors and management.

RESSOURCES
• https://www.owasp.org/index.php/Logging_Cheat_Sheet
Error_Handling,_Auditing_and_Logging
• https://www.owasp.org/index.php/Reviewing_Code_for_Logging_Issues
• https://www.owasp.org/index.php/OWASP_AppSensor_Project

A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A1A9 - Using
Components with
Known
Vulnerabilities

LEVERAGE SECURITY FRAMEWORKS AND LIBRARIES
PROBLEM STATEMENT
• Starting from scratch when it comes to developing security controls for
every web application, web service or mobile application leads to wasted
time and massive security holes.

CONTROL EXPLAINED
• When possible, the emphasis should be on using the existing secure
features of frameworks rather than importing third party libraries. It is
preferable to have developers take advantage of what they’re already
using instead of forcing yet another library on them.
• Not all the frameworks are completely secured hence it is important to
build in additional security where possible, updating frequently and
verifying them for security early and often like any other software you
depend upon.

RESSOURCES
• https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet
• https://code.google.com/archive/p/mustache-security/
• https://docs.angularjs.org/guide/security

A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A1A9 - Using
Components with
Known
Vulnerabilities

ERROR AND EXCEPTION HANDLING
PROBLEM STATEMENT
• Implementing correct errors and exceptions handling isn’t exciting, but
like input data validation, it is an important part of defensive coding,
critical to making a system reliable as well as secure.
• Mistakes in error handling can lead to diﬀerent kinds of security
vulnerabilities.

CONTROL EXPLAINED
• Manage exceptions in a centralized manner to avoid duplicating try/catch
blocks in the code, and to ensure that all unexpected behaviors are
correctly handled inside the application.
• Ensure that error messages displayed to users do not leak critical data,
but are still verbose enough to explain the issue to the user.
• Ensure that exceptions are logged in a way that gives enough
information for Q/A, forensics or incident response teams to understand
the problem.

RESSOURCES
• https://www.owasp.org/index.php/Error_Handling
• https://www.owasp.org/index.php/Testing_for_Error_Handling
• https://www.owasp.org/index.php/Improper_Error_Handling

A1 - Injection
A2 - Broken
Authentication
and Session
Management
A3 - Cross-Site
Scripting (XSS)
A4 - Broken Access
Control
A5 - Security
Misconﬁguration
A6 - Sensitive Data
Exposure
A10 -
Underprotected
APIs
A7 - Insuﬃcient
Attack Protection
A8 — Cross-Site
Request Forgery
(CSRF)
A1A9 - Using
Components with
Known
Vulnerabilities

ANY QUESTIONS?
THANK YOU!
If you want to talk more,
feel free to contact me.
http://kuzzle.io
This presentation was created using Keynote. The text
is set in Oswald and Ubuntu. The source code is set in
Ubuntu Mono. The iconography is provided by Keynote,
kuzzle.io and Font Awesome.
Unless otherwise noted, all photographs are used by
permission under a Creative Commons license. Please
refer to the Photo Credits slide for more information.
Copyright ©
This work is licensed under Creative Commons
Attribution-ShareAlike 4.0 International. For uses not
covered under this license, please contact the author.
hello@kuzzle.io
@kuzzleio
Kuzzle
kuzzleio
http://kuzzle.io
Browser Serving Your Web Application Security
2014-2017 Philippe Gamache
GAMACHE, Philippe. “Browser Serving Your Web
Application Security” NorthEast PHP Conference.
August 10, 2017. Conference presentation.
pgamache@kuzzle.io
@philoupedia
philippegamache
joind.in/talk/b137b
Please visit us at:

OWASP Top 10 Proactive Controls 2016 - NorthEast PHP 2017

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to OWASP Top 10 Proactive Controls 2016 - NorthEast PHP 2017

Similar to OWASP Top 10 Proactive Controls 2016 - NorthEast PHP 2017 (20)

More from Philippe Gamache

More from Philippe Gamache (16)

Recently uploaded

Recently uploaded (20)

OWASP Top 10 Proactive Controls 2016 - NorthEast PHP 2017