Secure Coding principles by example: Build Security In from the start - Carlo Bonamico - Codemotion Tech Meetup Tour 2015 - Genova

@carlobonamico@codemotionit
Secure Coding principles by example:
Build Security In from the start
Carlo Bonamico
@carlobonamico
carlo.bonamico@nispro.it
http://www.nispro.it
Genova, 29/10/2015
http://juggenova.wordpress.com

Evolution of Application Security
When I taught my first Web Application Security training
– most participants had never heard of SQL Injection and XSS
Thanks to many industry and community players (especially OWASP),
– not to mention many high-profile incidents,
things have started to change... Application Security
Ensuring Application
guarantees
•Confidentiality
•Integrity
•Availability
•Accountability
of the Information
it processes

Are we doing better?
It's 2015... we were promised flying cars... and what we got is...
See also
– http://www.cvedetails.com/vulnerabilities-by-types.php
– https://www.whitehatsec.com/resource/stats.html

Top Ten Web Application Risks
– A1-Injection
– A2-Broken Authentication and Session Management
– A3-Cross-Site Scripting (XSS)
– A4-Insecure Direct Object References
– A5-Security Misconfiguration
– A6-Sensitive Data Exposure
– A7-Missing Function Level Access Control
– A8-Cross-Site Request Forgery (CSRF)
– A9-Using Components with Known Vulnerabilities
– A10-Unvalidated Redirects and Forwards
Can we avoid them just by end-of-project Test and Patches?

First problem
Spiderman's Uncle Ben version:
With great power comes great responsibility...
The Web Application Security version:
With great power come more holes and greater risks!
– increased Surface of Attack

Websockets, storage, apis...
– https://html5sec.org/
– http://html5security.org/
– and once you penetrate the browser, you can do basically everything

and I mean it: calling APIs, install keyloggers, redirect user behaviour,
capture private data
–http://xenotix.in/
“most attack were already possible...
but they are more powerful now”
http://w3af.org/understanding-html5-security

Second problem
We are undergoing a wide architectural shift from
To
So many security assumptions do not hold true anymore!
ServerPOST params
HTML
Browser
Form-based
input
HTML rendering
HTML templating
Controllers,
Interaction
Logic
Business Logic
Server
POST JSON
JSON
Browser
HTML rendering
HTML templating
Business Logic
Interaction
Logic
REST
endpoints

The cost of fixing a security bug
●
Increases exponentially
– With time
– With project complexity
– With intergation phases
– With project advancement
• Analysis-test-production

So...
We need to care about Security from the beginning of the project
– During Analysis
– During Architecture & Design
– During Implementation
– and obvioulsy final testing
Making system secure is easy and almost effortless if you do it right
from the beginning
– much more expensive to add Security later
– often just so expensive that we do not do it

Secure Coding Principles
Follow the principles
of secure coding during Design
and Implementation
– and also deployment
– Do not trust inputs
– Minimize attack surface area
(and window of opportunity)
– Establish secure defaults
– Principle of Least privilege
– Principle of Defense in depth
– Fail securely
– Don’t trust services
– Separation of duties (vs
configuration)
– Avoid security by obscurity
– Keep security simple
– Fix security issues correctly
– If you can't protect, detect
– Get your users involved

Do not trust inputs
Would you execute to the letter all inputs that the world sends to
you?

Do not trust inputs
Any external input may carry an attack vector
Identify all external inputs
Filter and/or validate accordingly
Do not use unvalidated external input
– to perform security-sensitive operations
– ideally, to perform any operation

A3 - XSS
Cross-Site-Scripting means that attacker can insert custom js code which is
then displayed in the user browser
– stored (input js in a field → DB → sent back to the page)
– reflected (input js in the url, send the url to a user, js executed)
– DOM-based (input triggers js logic that manipulates the DOM and insert
custom js)
Remember: any external input is UNTRUSTED!
– so we must avoid mixing user input with js code
The proper solution is ESCAPING: encoding the data so that the browser
properly interprets it as plain text (and not js)
– https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Remember
Most vulnerabilities are not so serious by themselves
– but became terrible if mixed

think Pepsi + Mentos
XSS is an enabler for
– phishing
– browser-based MITM
– session / auth token stealing
– sensitive data extraction
– img courtesy of http://www.delawaretoday.com/

Minimize attack surface area

Minimize attack surface area
Surface Area
– the less exposed entry points, the better
– it is easier to protect a build with less doors and windows
So, avoid unnecessary features, pages, inputs, libraries, instsalled
components, etc.

Minimize window of opportunity

Technical definition
Window of Opportunity
– if there is a vulnerability, the time frame in which it can be
exploited should be as short as possible
– if I forget my door open, the longer I leave it open the riskier it is
E.g. time validity of a reset password link

Token Storage vs Session Duration
In memory or sessionStorage
– works only on current tab
– automatically closed
In localStorage
– persistent
– work across multiple tabs
– requires explicit expiration
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-
html5-web-storage/

Establish secure defaults

Establish secure defaults
The system should be secure by default
Users / installers should deliberatedly need to make specific
features more open if needed

Secure defaults - examples
A single MITM (Man in the Middle) and your “done”
– as the attacker can put arbitrary code in your browser
– so,

https://www.eff.org/Https-everywhere
Be careful with CORS
– Avoid AllowOrigin “*” unless you have very strong authentication
and authorization
Remember to tell the browser to enable stronger protection
– typically through headers such as CSP
– https://www.owasp.org/index.php/List_of_useful_HTTP_headers

Positive model
A "positive" security model (also known as "whitelist") is one that
defines what is allowed, and rejects everything else.
This should be contrasted with a "negative" (or "blacklist")
security model, which defines what is disallowed, while implicitly
allowing everything else.
The benefit of using a positive model is that new attacks, not
anticipated by the developer, will be prevented. However, the
negative model can be quite tempting when you're trying to
prevent an attack on your site.

Principle of Least privilege

Principle of Least privilege
Any tool/component/library/process should run with the minimal
privileges required to perform its function
– ideally, gain more privileged access only for the short time it is
actually required
Important for damage control
This includes
– OS user
– db access credentials
– web service access credentials
– security policies (e.g. JVM or browser policies)

Principle of Defense in depth

Principle of Defense in depth
Relying only on the system being disconnected from a larger
network, or on a perimeter-level check is not enough
Have different layers of protection
– e.g. UI / logic / DB

Fail securely

Fail securely
Errors should always be managed
– to limit unpredicatable behaviour
Errors should not lead to access
– default should be deny access
Errors should not leak information
– “could not connect to db X on server Y with user T and
password Z”
– stack traces
Split information useful for the developer from information useful
for the user

Don’t trust services

Don’t trust services
If you do not manage it, it might already be compromised
If you store sensitive information in external services
– don't do it
– and if you need, encrypt it

Separation of duties

The good side
In our consulting/project/problem solving experience,
the single biggest cause of
– quality
– performance
– security
problems is....

The good side
In our consulting/project/problem solving experience,
the single biggest cause of
– quality
– performance
– security
problems is....
the mixing & coupling of UI and business logic

Separation of duties
Leverage good OO Design principles
– DRY
– separation of concerns
– modularity
Separate configuration from business logic

Avoid security by obscurity

Avoid security by obscurity
Security should rely on specific keys/secrets/credentials not being
known,
not on the algorithm being unknown
– split a smaller secret from the rest of the system
– Kerchoff principle
Techniques for reverse engineering are very powerful now
– Java is very easy to decompile
If it is obscure, maybe it has not been reviewed enough

Keep security simple

Keep security simple
The less “moving parts”, the easier it is to check that everything
is correct

Fix security issues correctly

Fix security issues correctly
Beware of the “quick patch”
– often leads to further bugs later on
Five Whys
– why was this problem here?
– how to fix it
– how to prevent it?
– what do we need to prevent it?
Treat security bugs as airplane crash
– post-mortem
– take measures

Question to ask
What if the rules change?
What if an auditor wants to check if we actually follow the policy?

Role Based Access Control
Separating Role definition from Permission check
– In each service / action, code checks that the user has the relevant
permission
if (subject.hasPermission(“deletePost”))
– Role Definition lists all the permissions

e.g.
–Admin detelePost, updatePost, readPost→
–anonymous readPost→
Authorization system maps user/groups to list of roles
– and computes the “merged” set of permissions active for the valid user

user is both Admin & Editor

Permissions are
–changeSettings, deleteUser, addUser, deletePost,
modifyPost

Advantages
Permission check is
– focused, readable
– easy to implement
– easy to test
– rarely changes
Role definition is
– centralized
– easy to review
– easy to change
– as it tends to change often
Secure Design Principle
all parts of the system
need to perform security
checks
but
security check
implementation
should be centralized and
not “spread” in the system

If you can't protect, detect

If you can't protect, detect
If you know that an attack / issue is in progress
– you can activate remediation measures
Log and monitor
– critical operations

auth failues, misconfigurations, privileged actions
– resource usage
Do this securely
– do not log credentials and other user sensitive information

Intrusion detection
Detecting intrusions requires three elements:
the capability to log security-relevant events
procedures to ensure the logs are monitored regularly
procedures to properly respond to an intrusion once detected
You should log all security relevant information.
Detecting intrusions is important because otherwise you give the
attacker unlimited time to perfect an attack

Application Layer Intrusion
Detection
Really, important!
– Arguably one of the most important security mechanisms
– Simply not done in the wild
ESAPI Intrusion detection Key features
– Log Intrusion
– Logout User
– Disable Account
Configurable Thresholds

Get your users involved
If you lose it, call
800-999-666

Code cannot do everything
(at least with finite resources)
Give users the info they need to identify and correct security
issues themselves
– Educate your users
– Care about trust
– feedback to user about his connection

last login

notify relevant changes and events

@YourTwitterHandle#DVXFR14{session hashtag} @carlobonamico@codemotionit
A
f
nal
w
ord
...
But isn't all that unnecessary complexity
slowing down development of my critical project?

A final word
People tend to view Security as “overhead”, not adding value to the project
The reality:
– if you know what to pay attention to, minimal additional costs
– also, in most cases, adding security just means following good design principles
if you separate well concerns, adding security is easy
– favor clarity of intent and code readability
– favor composition over inheritance
– test, test, test!

incorporate security checks in your tests
This lets software adapt more easily to both requirements & security changes
– easier to evolve incrementally & validating each step → see Continuous
Delivery

References

References
Owasp Secure Coding Principles
– https://www.owasp.org/index.php/Secure_Coding_Principles
OWASP Testing Guide
– https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_
of_Contents
SOLID Design Principles
– http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Thank You for your attention
Interested?
– attend our Web Application Security / Angular trainings
– engage us for Design/Code Reviews, Vulnerability Assessments &
team mentoring
Read more on
– http://www.nispro.it
– http://www.slideshare.net/carlo.bonamico
Follow us on twitter
– @nis_srl @carlobonamico

updates on Security, AngularJS, Continuous Delivery
Contact me
– carlo.bonamico@gmail.com / carlo.bonamico@nispro.it

Secure Coding principles by example: Build Security In from the start - Carlo Bonamico - Codemotion Tech Meetup Tour 2015 - Genova

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Secure Coding principles by example: Build Security In from the start - Carlo Bonamico - Codemotion Tech Meetup Tour 2015 - Genova

Similar to Secure Coding principles by example: Build Security In from the start - Carlo Bonamico - Codemotion Tech Meetup Tour 2015 - Genova (20)

More from Codemotion

More from Codemotion (20)

Recently uploaded

Recently uploaded (20)

Secure Coding principles by example: Build Security In from the start - Carlo Bonamico - Codemotion Tech Meetup Tour 2015 - Genova