%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
Secure Coding principles by example: Build Security In from the start - Carlo Bonamico - Codemotion Tech Meetup Tour 2015 - Genova
1. @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
2. @carlobonamico@codemotionit
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
3. @carlobonamico@codemotionit
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
4. @carlobonamico@codemotionit
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?
5. @carlobonamico@codemotionit
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
6. @carlobonamico@codemotionit
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
7. @carlobonamico@codemotionit
The cost of fixing a security bug
●
Increases exponentially
– With time
– With project complexity
– With intergation phases
– With project advancement
• Analysis-test-production
8. @carlobonamico@codemotionit
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
9. @carlobonamico@codemotionit
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
11. @carlobonamico@codemotionit
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
12. @carlobonamico@codemotionit
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
13. @carlobonamico@codemotionit
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/
15. @carlobonamico@codemotionit
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.
17. @carlobonamico@codemotionit
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
18. @carlobonamico@codemotionit
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/
21. @carlobonamico@codemotionit
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
22. @carlobonamico@codemotionit
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.
24. @carlobonamico@codemotionit
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)
26. @carlobonamico@codemotionit
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
28. @carlobonamico@codemotionit
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
30. @carlobonamico@codemotionit
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
33. @carlobonamico@codemotionit
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
36. @carlobonamico@codemotionit
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
40. @carlobonamico@codemotionit
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
42. @carlobonamico@codemotionit
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
43. @carlobonamico@codemotionit
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
45. @carlobonamico@codemotionit
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
46. @carlobonamico@codemotionit
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
49. @carlobonamico@codemotionit
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
51. @carlobonamico@codemotionit
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
54. @carlobonamico@codemotionit
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