[OPD 2019] .NET Core Security

.NET CORE SECURITY
DANIEL KRASNOKUCKI, EQUINIX

/ AppSec
/ DevSecOps
/ .NET Developer
/ Trainer
2.NET CORE SECURITY | DANIEL.KRASNOKUCKI@OWASP.ORG | OWASP POLAND DAY | 16.10.2019
WHOAMI

AGENDA
1. What is .NET Core?
2. .NET (Core) risks and issues
3. Common mistakes when using .NET Core
4. .NET Core (not only) security practices

.NET CORE

.NET CORE
.NET Core (2014) is an open-source, general-purpose development platform
maintained by Microsoft and the .NET community on GitHub. It's cross-platform
(supporting Windows, macOS, and Linux) and can be used to build device, cloud,
and IoT applications.
.NET CORE SECURITY | DANIEL.KRASNOKUCKI@OWASP.ORG | OWASP POLAND DAY | 16.10.2019 5

.NET CORE

.NET CORE 3.0 - SEPTEMBER 2019

.NET CORE 3.0 - SEPTEMBER 2019
‣ GDPR ready
‣ HTTP/2 enabled by default
‣ gRPC
‣ EventCounters on request
‣ Forwarded Headers Middleware options
‣ One packed executable ﬁle

.NET CORE RISKS AND ISSUES

.NET CORE VALIDATION PROBLEMS
10
‣ Laziness (our laziness… not .NET)
‣ Tools ﬁrst! (we do not think)
‣ Front-end validation
‣ Improper feedback for the user
.NET CORE SECURITY | DANIEL.KRASNOKUCKI@OWASP.ORG | OWASP POLAND DAY | 16.10.2019

INSECURE DESERIALISATION
Insecure deserialization often leads to remote code execution. Even if
deserialization ﬂaws do not result in remote code execution, they can be used to
perform attacks, including replay attacks, injection attacks, and privilege
escalation attacks.
{ 
"$type": "System.Windows.Data.ObjectDataProvider, PresentationFramework",  
“ObjectInstance": {  
"$type":"System.Diagnostics.Process, System”},  
"MethodParameters":{  
"$type":"System.Collections.ArrayList, mscorlib",  
"$values":["calc"]},  
"MethodName":"Start"  
}

ANY FLOWS IN .NET?

COMMON MISTAKES WHEN USING .NET CORE

SECURITY MISCONFIGURATION
Security misconfiguration is the most commonly seen issue. This is a result of
insecure default configurations, incomplete or ad hoc configurations, open cloud
storage, misconfigured HTTP headers, and verbose error messages containing
sensitive information. Not only must all operating systems, frameworks, libraries,
and applications be securely configured, but they must be patched/upgraded in
a timely fashion.

USERS AND PROGRAMERS VS. SECURITY

SQL INJECTION - STILL…
16
www.somestore.com/Products.aspx?CategoryID=1
www.somestore.com/Products.aspx?CategoryID=1 or 1=1

IENUMERABLE<T> VS. IQUERYABLE<T>
17
‣ IEnumerable is best to query data from in-memory
collections like List, Array, etc.
‣ While query data from a database, IEnumerable
execute a select query on the server side, load data in-
memory on a client-side and then ﬁlter data.
‣ IEnumerable doesn’t support custom query.
‣ IEnumerable doesn’t support lazy loading. Hence not
suitable for paging like scenarios.
‣ Extension methods support by IEnumerable takes
functional objects.
‣ IQueryable is best to query data from out-memory
(like remote database, service) collections.
‣ While query data from a database, IQueryable
execute the select query on the server side with all
ﬁlters.
‣ IQueryable supports custom query using CreateQuery
and Execute methods.
‣ IQueryable support lazy loading. Hence it is suitable
for paging like scenarios.
‣ Extension methods support by IQueryable takes
expression objects means expression tree.
USING WRONG TYPES

IENUMERABLE<T> VS. IQUERYABLE<T> WITH ENTITY FRAMEWORK…
18
public IQueryable<Customer> GetCustomer(int customerId)
‣ A consumer of this query can call .Include("Orders") on the returned IQueryable<Customer> to retrieve data that the
query did not intend to expose. This can be avoided by changing the return type of the method to IEnumerable<T> and
calling a method (such as .ToList()) that materializes the results.
‣ Because IQueryable<T> queries are executed when the results are iterated over, a consumer of a query that exposes
an IQueryable<T> type could catch exceptions that are thrown. Exceptions could contain information not intended for the
consumer.
TIP: Avoid returning IQueryable<T> types from methods that are exposed to potentially untrusted callers

INFORMATION DISCLOSURE - LOOKS FAMILIAR?

POSSIBLE .NET MISCONFIGURATIONS
‣ Missing appropriate security hardening across any part of the application stack, or improperly
conﬁgured permissions on cloud services.
‣ Unnecessary features are enabled or installed
‣ Default accounts and their passwords still enabled and unchanged
‣ Error handling without custom errors
‣ For upgraded systems, latest security features are disabled or not conﬁgured securely
‣ The security settings in the application servers, application frameworks, libraries, databases, etc.
not set to secure values.
‣ The server does not send security headers or directives or they are not set to secure values.

BROKEN AUTHENTICATION AND AUTHORIZATION
Application functions related to authentication, authorization 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.

ACCESS CONTROL - MISUNDERSTANDING
Restrictions on what authenticated users are allowed to do are often not properly
enforced. Attackers can exploit these ﬂaws to access unauthorized functionality
and/or data, such as access other users' accounts, view sensitive ﬁles, modify
other users' data, change access rights, etc.

IDOR (INSECURE DIRECT OBJECT REFERENCES)
www.mybestandonlystore.com/orders/id=900

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
defences and enable various attacks and impacts.

INSUFFICIENT LOGGING & MONITORING
Insufﬁcient logging and monitoring, coupled with missing or ineffective
integration with incident response, allows attackers to further attack systems,
maintain persistence, pivot to more systems, and tamper, extract, or destroy data.
Most breach studies show time to detect a breach is over 200 days, typically
detected by external parties rather than internal processes or monitoring.

A1 - INJECTIONS
A2 - BROKEN
AUTHENTICATION
A3 - SENSITIVE DATA
EXPOSURE
A4 - XML EXTERNAL
ENTITIES
A5 - BROKEN ACCESS
CONTROL
A6 - SECURITY
MISCONFIGURATION
A7 - CROSS-SITE
SCRIPTING
A8 - INSECURE
DESERIALISATION
A9 - USING
COMPONENTS WITH
KNOWN
VULNERABILITIES
A10 - INSUFFICIENT
LOGGING &
MONITORING
OWASP TOP 10 WEB APPLICATION VULNERABILITIES

.NET SECURITY PRACTICES

IT’S MOSTLY SECURED BY DEFAULT IN .NET, BUT …
28
‣ Stop reinventing the wheel
‣ Do not be smarter than the framework
‣ If you use Razor, then use Razor. If you use something else, then use something
else, but do not use your own Blazor-ish, Razor-ish, MVC-ish, .NET-ish…
‣ Validate and whitelist each input and parameter
‣ Use proper output encoding

SQL INJECTION MITIGATION
29
‣ Use .NET security leading practices and OWASP Guidelines
‣ Parametrise your queries
‣ Validate the parameters from the user - ALWAYS!
‣ Use whitelisting of characters
‣ Check the length of the parameter
‣ App should have the minimum required permission in the system (not running
as an admin “because it’s easier and it’s working”)
‣ You can use ORM, but still think about returned types!

AUTHENTICATION - QUICK SETTINGS

SECURITY HEADERS

SECURITY HEADERS IN .NET CORE

CORS (CROSS-ORIGIN RESOURCE SHARING)
A mechanism that allows restricted resources on a web page to be requested
from another domain outside the domain from which the ﬁrst resource was
served.
A web page may freely embed cross-origin images, stylesheets, scripts, iframes,
and videos.[2] Certain "cross-domain" requests, notably Ajax requests, are
forbidden by default by the same-origin security policy.

CORS (CROSS-ORIGIN RESOURCE SHARING)

SECURITY CONFIGURATIONS IN .NET - COOKIES AND GDPR

INSECURE DESERIALISATION MITIGATION
‣ Do not deserialize untrusted data!
‣ … do not deserialize untrusted data!
‣ If you really need to deserialize:
‣ Make sure to evaluate the security and version of the chosen library
‣ Avoid libraries without strict type control
‣ Never use user-controlled data to deﬁne the deserializer expected Type
‣ Do not roll your own format

LOGGING IN .NET
37
Logging guidance from Microsoft
https://microsoft.github.io/code-with-engineering-playbook/Engineering/DevOpsLoggingDetailsCSharp.html
Where possible, always log:
• Input and output validation failures e.g. protocol violations, unacceptable encodings, invalid parameter names and
values
• Authentication successes and failures and Authorization (access control) failures
• Session management failures e.g. cookie session identiﬁcation value modiﬁcation
• Application errors and system events
• Application and related systems start-ups and shut-downs, and logging initialization (starting, stopping or pausing)
• Use of higher-risk functionality
• Legal and other opt-ins e.g. permissions for mobile phone capabilities, terms & conditions, PII data usage consent

HOW TO CHECK ALL OF THAT?
38
‣ Security Headers by Scott Helme - https://securityheaders.com/
‣ SSL Labs - https://www.ssllabs.com/ssltest/
‣ Hardenize - https://www.hardenize.com/
‣ OWASP checklists and security tools
‣ Some of linters/SAST tools available for .NET
✓ DevSkim
✓ FxCop (Microsoft Code Analysis)
✓ Sonar
✓ Puma

…?
Questions

TEXT
THANK YOU.
DZIĘKUJĘ.
DANIEL.KRASNOKUCKI@OWASP.ORG
42
PLEASE HAVE YOUR BADGE TO GET THE LUNCH!

[OPD 2019] .NET Core Security

More Related Content

What's hot

Similar to [OPD 2019] .NET Core Security

More from OWASP

Recently uploaded

[OPD 2019] .NET Core Security