Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
@carlobonamico@codemotionit
Secure Coding principles by example:
Build Security In from the start
Carlo Bonamico
@carlobon...
@carlobonamico@codemotionit
Evolution of Application Security
When I taught my first Web Application Security training
– m...
@carlobonamico@codemotionit
Are we doing better?
It's 2015... we were promised flying cars... and what we got is...
See al...
@carlobonamico@codemotionit
Top Ten Web Application Risks
– A1-Injection
– A2-Broken Authentication and Session Management...
@carlobonamico@codemotionit
First problem
Spiderman's Uncle Ben version:
With great power comes great responsibility...
Th...
@carlobonamico@codemotionit
Second problem
We are undergoing a wide architectural shift from
To
So many security assumptio...
@carlobonamico@codemotionit
The cost of fixing a security bug
●
Increases exponentially
– With time
– With project complex...
@carlobonamico@codemotionit
So...
We need to care about Security from the beginning of the project
– During Analysis
– Dur...
@carlobonamico@codemotionit
Secure Coding Principles
Follow the principles
of secure coding during Design
and Implementati...
@carlobonamico@codemotionit
Do not trust inputs
Would you execute to the letter all inputs that the world sends to
you?
@carlobonamico@codemotionit
Do not trust inputs
Any external input may carry an attack vector
Identify all external inputs...
@carlobonamico@codemotionit
A3 - XSS
Cross-Site-Scripting means that attacker can insert custom js code which is
then disp...
@carlobonamico@codemotionit
Remember
Most vulnerabilities are not so serious by themselves
– but became terrible if mixed
...
@carlobonamico@codemotionit
Minimize attack surface area
@carlobonamico@codemotionit
Minimize attack surface area
Surface Area
– the less exposed entry points, the better
– it is ...
@carlobonamico@codemotionit
Minimize window of opportunity
@carlobonamico@codemotionit
Technical definition
Window of Opportunity
– if there is a vulnerability, the time frame in wh...
@carlobonamico@codemotionit
Token Storage vs Session Duration
In memory or sessionStorage
– works only on current tab
– au...
@carlobonamico@codemotionit
Establish secure defaults
@carlobonamico@codemotionit
Establish secure defaults
The system should be secure by default
Users / installers should del...
@carlobonamico@codemotionit
Secure defaults - examples
A single MITM (Man in the Middle) and your “done”
– as the attacker...
@carlobonamico@codemotionit
Positive model
A "positive" security model (also known as "whitelist") is one that
defines wha...
@carlobonamico@codemotionit
Principle of Least privilege
@carlobonamico@codemotionit
Principle of Least privilege
Any tool/component/library/process should run with the minimal
pr...
@carlobonamico@codemotionit
Principle of Defense in depth
@carlobonamico@codemotionit
Principle of Defense in depth
Relying only on the system being disconnected from a larger
netw...
@carlobonamico@codemotionit
Fail securely
@carlobonamico@codemotionit
Fail securely
Errors should always be managed
– to limit unpredicatable behaviour
Errors shoul...
@carlobonamico@codemotionit
Don’t trust services
@carlobonamico@codemotionit
Don’t trust services
If you do not manage it, it might already be compromised
If you store sen...
@carlobonamico@codemotionit
Separation of duties
@carlobonamico@codemotionit
The good side
In our consulting/project/problem solving experience,
the single biggest cause o...
@carlobonamico@codemotionit
The good side
In our consulting/project/problem solving experience,
the single biggest cause o...
@carlobonamico@codemotionit
Separation of duties
Leverage good OO Design principles
– DRY
– separation of concerns
– modul...
@carlobonamico@codemotionit
Avoid security by obscurity
@carlobonamico@codemotionit
Avoid security by obscurity
Security should rely on specific keys/secrets/credentials not bein...
@carlobonamico@codemotionit
Keep security simple
@carlobonamico@codemotionit
Keep security simple
The less “moving parts”, the easier it is to check that everything
is cor...
@carlobonamico@codemotionit
Fix security issues correctly
@carlobonamico@codemotionit
Fix security issues correctly
Beware of the “quick patch”
– often leads to further bugs later ...
@carlobonamico@codemotionit
Question to ask
What if the rules change?
What if an auditor wants to check if we actually fol...
@carlobonamico@codemotionit
Role Based Access Control
Separating Role definition from Permission check
– In each service /...
@carlobonamico@codemotionit
Advantages
Permission check is
– focused, readable
– easy to implement
– easy to test
– rarely...
@carlobonamico@codemotionit
If you can't protect, detect
@carlobonamico@codemotionit
If you can't protect, detect
If you know that an attack / issue is in progress
– you can activ...
@carlobonamico@codemotionit
Intrusion detection
Detecting intrusions requires three elements:
the capability to log securi...
@carlobonamico@codemotionit
Application Layer Intrusion
Detection
Really, important!
– Arguably one of the most important ...
@carlobonamico@codemotionit
Get your users involved
If you lose it, call
800-999-666
@carlobonamico@codemotionit
Code cannot do everything
(at least with finite resources)
Give users the info they need to id...
@YourTwitterHandle#DVXFR14{session hashtag} @carlobonamico@codemotionit
A
f
nal
w
ord
...
But isn't all that unnecessary c...
@carlobonamico@codemotionit
A final word
People tend to view Security as “overhead”, not adding value to the project
The r...
@carlobonamico@codemotionit
References
@carlobonamico@codemotionit
References
Owasp Secure Coding Principles
– https://www.owasp.org/index.php/Secure_Coding_Prin...
@carlobonamico@codemotionit
Thank You for your attention
Interested?
– attend our Web Application Security / Angular train...
Próxima SlideShare
Cargando en…5
×

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

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

Audiolibros relacionados

Gratis con una prueba de 30 días de Scribd

Ver todo

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

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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
  10. 10. @carlobonamico@codemotionit Do not trust inputs Would you execute to the letter all inputs that the world sends to you?
  11. 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. 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. 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/
  14. 14. @carlobonamico@codemotionit Minimize attack surface area
  15. 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.
  16. 16. @carlobonamico@codemotionit Minimize window of opportunity
  17. 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. 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/
  19. 19. @carlobonamico@codemotionit Establish secure defaults
  20. 20. @carlobonamico@codemotionit Establish secure defaults The system should be secure by default Users / installers should deliberatedly need to make specific features more open if needed
  21. 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 Allow­Origin “*” 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. 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.
  23. 23. @carlobonamico@codemotionit Principle of Least privilege
  24. 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)
  25. 25. @carlobonamico@codemotionit Principle of Defense in depth
  26. 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
  27. 27. @carlobonamico@codemotionit Fail securely
  28. 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
  29. 29. @carlobonamico@codemotionit Don’t trust services
  30. 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
  31. 31. @carlobonamico@codemotionit Separation of duties
  32. 32. @carlobonamico@codemotionit The good side In our consulting/project/problem solving experience, the single biggest cause of – quality – performance – security problems is....
  33. 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
  34. 34. @carlobonamico@codemotionit Separation of duties Leverage good OO Design principles – DRY – separation of concerns – modularity Separate configuration from business logic
  35. 35. @carlobonamico@codemotionit Avoid security by obscurity
  36. 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
  37. 37. @carlobonamico@codemotionit Keep security simple
  38. 38. @carlobonamico@codemotionit Keep security simple The less “moving parts”, the easier it is to check that everything is correct
  39. 39. @carlobonamico@codemotionit Fix security issues correctly
  40. 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
  41. 41. @carlobonamico@codemotionit Question to ask What if the rules change? What if an auditor wants to check if we actually follow the policy?
  42. 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. 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
  44. 44. @carlobonamico@codemotionit If you can't protect, detect
  45. 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. 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
  47. 47. @carlobonamico@codemotionit 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
  48. 48. @carlobonamico@codemotionit Get your users involved If you lose it, call 800-999-666
  49. 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
  50. 50. @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?
  51. 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
  52. 52. @carlobonamico@codemotionit References
  53. 53. @carlobonamico@codemotionit 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
  54. 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

×