Essential security measures in ASP.NET MVC

Photo: https://www.pinterest.ca/pin/176203404146573009/
Is it safe?

Essential security measures
in ASP.NET MVC

Rafał Hryniewski
@r_hryniewskifb.me/hryniewskinet

Agenda
• Glossary
• Should developer be responsible for security?
• OWASP Top 10
• A little bit more of security stuff
• Summary
• Questions

Glossary
• Vulnerability
• OWASP – Open Web Application Security Project
• CWE – Common Weakness Enumeration
• CVE - Common Vulnerability Enumeration
• ASVS – Application Security Verification Standard

Systems have vulnerabilities…
Photo: https://www.flickfilosopher.com/2010/06/doctor-who-blogging-the-lodger.html

…and some people have bad intentions
Photo: https://tookapic.com/photos/25299

“Oops” in security can cost fuckton of money…
Photo: https://www.youtube.com/watch?v=PJpr7L7N2Ho

…so security experts earn shitload of money
Photo: https://gif-free.com/278-breaking-bad-money.html

But do you need to be security expert to secure
your product?
Photo: http://favoritememes.com/news/mom_trust_me_i_m_a_professional/2014-07-29-395

TL;DR
Vid. https://www.youtube.com/watch?v=cAhvfRZZpPk

OWASP Top 10 - 2017
1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with Known Vulnerabilities
10.Insufficient Logging & Monitoring

Injection – Are you vulnerable?
• Do you concatenate strings in order to build database queries
or OS commands?
• Does your ORM protect you from injection?
• Do you validate internal and external inputs?

Injection - Example
var productName = "userInput";
var sql = "SELECT * FROM [dbo].[Products]
WHERE [Name] = '" + productName + "'";

Injection - Example
var productName = "userInput";
var sql = "SELECT * FROM [dbo].[Products]
WHERE [Name] = @productName";
var result =
ctx.Database.SqlQuery<Product>(sql,
new SqlParameter("productName",
productName))
.ToList();

Injection – Dos and don’ts
Do
• Validate inputs
• Whitelist inputs
• Use named parameters
• Use parametrized functions
and procedures
Don’t
• Trust exernal inputs
• Trust internal inputs
• Concatenate dynamic queries
and commands
• Use privileged accounts in
connection strings

Injection - Demo
Photo: http://fr.memegenerator.net/instance/46889228/mchammer-stop-demo-time

Broken authentication
Photo: http://skillprogramming.com/recent/you-entered-joe-smiths-password-may-be-your-email-is-joesmithgmailcom-1136832

Broken authentication – are you vulnerable?
• Do you have any brute force protection on sign in form?
• Do you indicate that account exists while someone post wrong
password?
• Is it possible to steal your session token? Does EVERY request
goes through HTTPS?
• Are your session cookies protected with secure flag?
• Do you use multi factor authentication?
• How long is your session timeout?

Broken authentication – Dos and don’ts
Do
• Require strong passwords
• Use Multi Factor
Authentication
• Check if password was
present in any data leak
(haveibeenpwned.com)
• Log and monitor
authentication failures
Don’t
• Allow for infinite sign in
attempts
• Send or display passwords in
any way
• Use long session timeouts

Broken authentication - demo
Photo: https://makeameme.org/meme/brace-yourself-demo

Sensitive Data Exposure
Photo: https://memegenerator.net/instance/74308018/what-if-i-told-you-what-if-i-told-you-ill-never-stop-talking-about-sensitive-data

Sensitive Data Exposure – are you vulnerable?
• Can any request be made without encryption?
• Do you store any sensitive and not encrypted data?
• Do you use obsolete and weak cryptography algorithms?

Sensitive Data Exposure – Dos and don’ts
Do
• Use HTTPS and HSTS
• Encrypt sensitive data
• Identify which data should be
considered sensitive
Don’t
• Store and/or send sensitive
data in plain text
• Allow for non-SSL browsing
• Use weak encryption
algorithms (SHA1 etc.)

XML External Entities
Photo: https://dev.to/rionmonster/hello-xml-my-old-friend-ive-come-to-encode-you-again-3iip

XML External Entities – are you vulnerable?
• Do you use XML at all?
• Do you sanitize your inputs?
• Do you use whitelists for input validations?

XML External Entities – Dos and don’ts
Do
• Use HTTPS and HSTS
• Encrypt sensitive data
• Know which data should be
considered sensitive
Don’t
• Store and/or send sensitive
data in plain text
• Allow for non-SSL browsing
• Use weak encryption
algorithms (SHA1 etc.)

Broken Access Control
Photo: https://imgflip.com/memetemplate/70001743/You-Shall-Not-Pass

Broken Access Control – are you vulnerable?
• Are you checking permissions at all?
• Do you handle permissions on frontend?
• Can you access endpoints you shouldn’t by modifying URLs or
cookies?

Broken Access Control – Dos and don’ts
Do
• Use role based access
control
• Handle permissions on
server-side
• Always check if someone is
allowed to do something
Don’t
• Think someone will never
guess your unsecured admin
route
• Allow changing of application
state to unauthorized user

Broken Access Control – demo
Photo: https://imgflip.com/i/21acb2

Security Misconfiguration
Photo: https://www.jeffgeerling.com/blogs/jeff-geerling/devops-server-deployment-and

Security Misconfiguration – are you vulnerable?
• Do you have any default accounts active?
• Is it possible to see error and stack traces in your application
when exception happen?
• Have you disabled security features because they were
annoying an d/or inconvenient?
• Does your application use any security headers?

Security Misconfiguration – Dos and don’ts
Do
• Remove or change any
default credentials
• Use accounts with least
needed privileges
• Use security headers
• Configure and turn on
framework/server/etc.
Security features
Don’t
• Use the same credentials on
test, dev and prod
environments
• Install or turn on any features
you don’t need
• Reveal error messages and
sensitive system informations
• Remove security features
because they bother you

Security Misconfiguration – examples

Security Misconfiguration – examples
Screenshot: https://packetstormsecurity.com/files/111277/Microsoft-ASP.NET-Forms-Authentication-Bypass.html

Security Misconfiguration – web.config examples
<customheaders>
<remove name="X-Powered-By" />
</customheaders>
<system.web>
<httpRuntime targetFramework="4.5" enableVersionHeader="false"/>
<httpCookies requireSSL="true"/>
</system.web>

Security Misconfiguration – global.asax examples

Security Misconfiguration – fixed!

Security Misconfiguration – or not!

Security Misconfiguration – always!
<customErrors mode=“On" />

Cross-Site Scripting (XSS)
Photo: https://memegenerator.net/instance/35924967/evil-doc-found-a-textbox-lets-try-script-alert-xss

XSS – are you vulnerable?
• Does your application return values like „Results for phrase X”?
• Do you store text with HTML tags for display purposes?
• Can I upload SVG file to your system and it’ll render it?
• Do you sanitize your inputs?

XSS – Dos and don’ts
Do
• Sanitize/escape untrusted
inputs
• Use Content Security Policy
header
• Use X-XSS-Protection header
• Use HTTPOnly flag on
sensitive cookies that
shouldn’t be used by JS
Don’t
• Allow users to upload SVG
files, if necessary – sanitize
them.
• Render user provided HTML -
formatted strings
• Return ContentType –
text/html if it’s JSON

XSS – Stored XSS
Case when you store insecure values in some kind of persistent
storage and render it afterwards (ie. comments)

XSS – Reflected XSS
Case when you return and render some kind of user input back
(ie. Search results for phrase: ‘<script>alert(“XSS”)</script>’

Insecure Deserialization
Photo: https://github.com/tgockel/json-voorhees/blob/master/README.md

Insecure Deserialization – are you vulnerable?
• Can you change sensitive application state or behavior (ie.
Authorization) by sending modified, serialized value?
• Can you modify type in which object will deserialize?
• Do you validate field types after deserialization?

Insecure Deserialization – Dos and don’ts
Do
• Validate inputs
• Keep important data on the
backend
Don’t
• Send and receive mutable,
sensitive data.
• Compile and execute
received code on server side

Using Components with Known Vulnerabilities
Photo: https://devrant.com/rants/760537/heaviest-objects-in-the-universe

Using Components with Known Vulnerabilities –
are you vulnerable?
• Did you ever check you components against vulnerabilities?
• Do you use updated libraries and frameworks?
• Do you use automated tools for checking components you’re
using?
• Do you know EXACTLY what are ALL dependencies of your
application?

Dos and don’ts
Do
• Use automated tools like
retire.js
• Always look for vulnerabilities
in stuff you install
• Perform regular updates
Don’t
• Ignore new versions of
libraries you’re using
• Use obsolete components

not scary?
Screenshot: https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2017/3214296

Insufficient Logging & Monitoring
Photo: https://apreed.wordpress.com/2018/04/13/day-136-discursive-essay-1-1984-pt-2-due-wed/amazing-all-the-things-meme-generator-the-roleplay-
cafe-roleplaying-and-writing-memes-just/

Insufficient Logging & Monitoring – are you
vulnerable?
• Will you know when someone will try to bruteforce your users
password?
• Do you use any kind of anomaly detection?
• Do you need to read your logs to know about attempts to
breach your security or you’ll receive instant alert?

Insufficient Logging & Monitoring– Dos and don’ts
Do
• Log any potential security
breaches or even attempts
• Use alerts
• Detect anomalies
Don’t
• Just store logs
• Wait for someone to read
gigabytes of logs

But it’s all simple stuff so far…
Screenshot: https://stackoverflow.com/questions/43249998/chrome-err-blocked-by-xss-auditor-details#

…and yet there’s still a lot of vulnerable
applications out there
Screenshot: https://stackoverflow.com/questions/43249998/chrome-err-blocked-by-xss-auditor-details#

Breaking stuff is easy because we haven’t made it
hard enough
Photo: http://www.dumpaday.com/funny-pictures/funny-i-dont-even-know-what-im-doing-30-pics/

More
Photo: http://knowyourmeme.com/memes/moar

HTTP Strict Transport Security
Photo: http://www.memegen.com/meme/g1sdfc

HTTP Strict Transport Security – Why?
• So, all your HTTP requests are redirected to HTTPS?
• But the first one is still not secure.

HTTP Strict Transport Security – what?
• It has great browser support and comes with preload list.
• All it takes is making your site secure and adding Strict-
Transport-Security header
• You can submit to preload list manually on
https://hstspreload.org

HTTP Strict Transport Security – Preload list

HTTP Strict Transport Security – Browser support

Content-Security-Policy
Photo: https://imgflip.com/i/pfov8

Content-Security-Policy
• A lot of various directives ie. Whitelisting script or styles files
sources, upgrading insecure urls, hide referrer etc.
• Allows to report CSP violations by HTTP request
• Directives reference - https://content-security-policy.com

Content-Security-Policy – Browser Support for L1

Content-Security-Policy – Browser Support for L2

Preparation for security audit
Photo: https://imgflip.com/memegenerator

Application Security Verification Standard - ASVS
• ASVS on OWASP site
• 3 levels
• Also has versions for mobile apps, IoT
• Basically a big checklist

Some tools
• Kali Linux
• W3af
• Zed Attack Proxy
• Sqlmap
• XSS Rays(browser extension)

Essential security measures in ASP.NET MVC

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Essential security measures in ASP.NET MVC

Similaire à Essential security measures in ASP.NET MVC (20)

Plus de Rafał Hryniewski

Plus de Rafał Hryniewski (17)

Dernier

Dernier (20)

Essential security measures in ASP.NET MVC