Security in .NET OWAS Top 10

1. Security .NET
-Abhi Jain

2. Agenda
● Security overview
● Security Mindset
● 4 day training
○ Each day
■ Discuss 2-3 security attacks
■ Learn how to prevent them
■ Hands on exercises
■ Homeworks
● Summary

3. A few things
● Need lots of participation
● 4 Day program
○ With a few breaks
● My aim for you is:
○ To have a very good understanding of Security in .NET applications
○ Familiarize yourself with various attacks and their prevention
○ Get the confidence of debugging/ fixing any issues
● Ask questions
● If I don’t know
○ I will find the answer for you
○ And send your way
● Add me on LinkedIn
○ To Stay connected

4. Introductions

5. About Me
● Lead Dev
● Located in Florida
● Trainer
● Presenter
● .NET Developer
● Youtuber: Coach4Dev
● Husband/ Father

6. Brain Teaser
● What do web developers say when they have to maintain the legacy SOAP
interface?
● "Just give me a REST."

7. Why Security?
● Hackers always out there
● Looking for ways to extort/ make money
● The more money the company makes
○ The more lucrative it is
● 1 big attack
○ Can bring a company to its knees
● Bad PR

8. Recent Security attacks
● CAM4
○ Mar 2020
○ 10.8 bln records: All users’ info
● LinkedIn
○ June 2021
○ 700 mln users
● FB
○ Apr 2019
○ 533 mln users’ data
● Ashley Madison
○ July 2015
○ 32 mln users
● https://www.upguard.com/blog/biggest-data-breaches

9. Security Mindset
● Think like a hacker
● How will anyone go about hacking it
● How will they break in
● Rings of security
● Nothing is perfectly secure
○ Neither is our home
● You have to make it just enough
○ So it acts as a deterrent

10. What is OWASP
● Open Web Application Security Project
● Non profit organization
● Works towards improving security of web

11. OWASP Top 10
● Standard awareness document for developers and web application security
● Represents a broad consensus about:
○ Most critical security risks to web applications
● Latest OWASP Top 10 was published in 2021

12. OWASP Top 10

13. Broken Access Control

14. Broken Access Control
● Top most security vulnerability
● Can be in many forms:
○ Violation of principle of least privilege
○ Bypassing access control checks
■ Modify URL/ API request, etc.
○ Elevation of privilege
■ Act as a user/ admin without being logged in
■ Act as admin when logged in as user

15. Principle of Least Privilege
● Subject should be given only those privileges needed for it to complete its
tasks.
● If a subject does not NEED an access right
○ Should not have it

16. How to remedy
● Follow principle of least privilege
● Except for public resources, deny by default
● Application data access/ manipulation should be enforced (by domain
models)
● Log access control failures and alert when needed
● Rate limit API and control access
○ API gateway can help
● Invalidate stateful session identifiers on server upon logout
● Stateless JWT tokens should be short lived

17. Exercise
● Break the Sample Expenses application
● You have a user:
○ user@user.com
○ He can't Approve an expense
○ Only Admin(s) can
● You need to approve the expense as a user :)

18. Cryptographic Failures

19. Brain Teaser
● Why did the cryptographer throw up at McDonalds?
● Because he couldn’t digest a big MAC

20. Cryptographic Failures
● Failures related to cryptography
○ Or lack of thereof
● Is any data transmitted in clear text?
● Old or weak cryptographic algorithms in use
● Is encryption not enforced?
● Are default crypto keys in use?
○ Are weak keys in use?
○ Is proper key management in place?
○ Is key rotation in place?

21. How to combat
● Classify your data and set protection standards accordingly
● Configure Https
○ Encrypt all data in transit
● Do not store sensitive data (if not necessary)
● Disable caching for response
○ With sensitive data
● Encrypt all sensitive data at rest
● Store passwords using
○ Strong adaptive and salted hashing functions with a work factor (delay factor)
○ E.g. Argon2, scrypt, bcrypt or PBKDF2.
● Key rotation

22. Example attack
● A site doesn't use or enforce TLS for all pages
● An attacker monitors network traffic (e.g., at an insecure wireless network)
○ Downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's
session cookie.
○ The attacker then replays this cookie and hijacks the user's (authenticated) session, accessing
or modifying the user's private data.
○ Instead of the above they could alter all transported data, e.g., the recipient of a money
transfer.

23. Another way to prevent

24. Exercise
● Understand how to securely save passwords in DB?
● MD5 Hash of common passwords
● https://hashtoolkit.com/common-passwords/

25. How .NET saves it?
● https://www.blinkingcaret.com/2017/11/29/asp-net-identity-passwordhash/

26. Injection

27. Injection
● One of the most common vulnerability
● User supplied data is not validated/ filtered/ sanitized
● Dynamic queries or non parameterized calls
○ Commonly used in SQL injection
● Hostile data is used within object-relational mapping (ORM) search
parameters to extract additional, sensitive records.

28. SQL Injection Scenario
● Ref: xkcd

29. XSS
● An attacker needs to insert
○ And execute malicious content
● E.g.
○ HTML
○ Javascript
○ CSS
● Sample scenario
○ Attacker able to inject Javascript in Amazon website
○ Every user who opens the webpage
■ Is vulnerable

30. XSS Exercise 1
● Add Malicious Javascript (disguised as HTML) in the code
● See it getting rendered
● On Expenses List page

31. Sample Attack
● HTML :
○ In Comments add:
■ </td><script>alert(‘HTML XSS’)</script>

32. XSS Exercise 2
● On the Edit expense
○ There is a pop up
○ Takes user input
○ And used in JS
● Using JS injection
○ Get a second pop up msg
○ Displaying “I am a hacker”

33. Sample Attack
● JS:
○ Edit page
■ Category: ‘);alert(‘Abhi’)//

34. SQL Injection Attack
● Details page is safe
● There is another page called DetailsVulnerable
● Aim:
○ Use SQL Injection to:
■ Approve all expenses
■ Delete all expenses

35. SQL Injection Attack
● Setting all expenses to approved
● /Expenses/DetailsVulnerable/2%20UPDATE%20Expense%20SET%20IsAppr
oved=1

36. How to Prevent
● Sanitize/ validate user inputs
● User server side input validation
● Principle of least privilege can help
○ Reduce amount of data exposed
○ Prevent Manipulation of data
● Proper encoding in place prevents XSS
○ HTML Encoding
○ Javascript Encoding
○ URL encoding, etc.

37. MIME Sniffing
● If you allow users to upload files to your application
● In HTTP response,
○ The server mentions Content-Type (Header)
● Attacker misguides the content type
● If the client browser notices an issue
○ MIME (Multipurpose Internet Mail Extensions) sniffing occurs
○ Tries to rectify the Content type
○ Might execute the script

38. Example Attack

39. How to Prevent
● Set X-Content-Type-Options : nosniff
● 2 ways:
● At code level:

40. Set Header at IIS level
● Open IIS Manager and on the left hand tree, left click the site you would like
to manage.
● Double click the “HTTP Response Headers” icon.
● Right click the header list and select “Add”
● For the “name” write “X-Content-Type-Options” and for the value “nosniff”

41. Insecure Design

42. Insecure Design
● Broad category
● Missing/Ineffective Control design
● Different from insecure implementation
● Many businesses fail to profile the business risk
○ Data classification
■ Which in turn decides level of security in design
● Lack of security in SDLC

43. Examples of Insecure Design
● Plaintext Storage of password
● Improper privilege management
● Reliance on Security through obscurity
● Not failing securely
● Improper isolation or Compartmentalization
● Use of Persistent Cookies Containing Sensitive Information
○ Cookies can be manipulated/ stolen, etc.
● Insecure storage in file or disk

44. Cookie Security
● Cookies get sent to server
● Set cookie to secure
○ Used only on HTTPS
○ https://docs.microsoft.com/en-us/dotnet/api/system.net.cookie.secure?view=net-6.0
● Set cookie to HTTP only
○ Javascript can’t touch it
○ https://docs.microsoft.com/en-us/dotnet/api/system.net.cookie.httponly?view=net-6.0

45. Local Storage
● Does not get sent to server
● JS only access
● If JS XSS attack is done - data can be stolen
● Server has no control - client can update anything
● Can persist in Client browser
○ Across sessions

46. Session Storage
● Does not get sent to server
● JS only access
● If JS XSS attack is done - data can be stolen
● Server has no control - client can update anything
● Gets deleted when
○ tab/ browser is closed

47. Security Misconfiguration

48. Security Misconfiguration
● Without a concerted, repeatable application security configuration process,
systems are at a higher risk
● Default accounts and their passwords are enabled/unchanged
● Unnecessary features are enabled/ installed
○ Unnecessary ports,
○ Services, etc.
● Error handling reveals stack traces or overly informative error messages
● Security settings not set to secure values
○ Application servers,
○ Application frameworks
● Out of date components

49. How to prevent
● Automate hardening process
○ Verify effectiveness of settings/ configurations
● Use similar settings in all environments (QA/Stage/Prod)
○ With different credentials
● Remove unused features and frameworks
● Stay on top of
○ Updates to components
○ Patches
● Segmented application architecture
○ Provides effective / secure separation b/w components

50. Developer Exception Page
● Use Developer Exception Page properly
● ASPNETCORE_ENVIRONMENT
○ To Development
○ On local machine for debugging
○ launchSettings.json file
● https://docs.microsoft.com/en-us/aspnet/core/fundamentals/error-handling?vie
w=aspnetcore-6.0#developer-exception-page
● https://docs.microsoft.com/en-us/aspnet/core/fundamentals/environments?vie
w=aspnetcore-6.0

51. Funny!

52. Vulnerable and Outdated Components

53. Vulnerable and Outdated Components
● OS
● Application/ web server
● Runtime environments
● DBMS
● APIs
● Libraries

54. Vulnerable and Outdated Components
● Using Third party components
○ With known vulnerabilities
● Not following updates/ patches

55. How to prevent
● Remove unused
○ Dependencies
○ Components
○ Features, etc.
● Check versions of
○ Client-side components
○ Server-side components
● Monitor sources:
○ Common Vulnerability and Exposures (CVE)
○ National Vulnerability Database (NVD)

56. How to prevent
● Obtain components from official sources
○ And Secure Links
● Proper plan in place
○ Monitoring, triaging & applying updates

57. Identification and Authentication Failures

58. Funny

59. Identification and Authentication Failures
● Confirm a user’s identity
○ Authentication
○ Session Management
● Vulnerable if:
○ Permitting brute force
○ Allowing weak passwords/ common passwords
○ Exposes session identifier in URL
○ Doesn’t invalidate session Id upon logout

60. Credential Stuffing
● Use stolen username and passwords
○ On website login forms
● Many users reuse their credentials
○ Could be exposed by data breach
○ Or phishing attacks
● Subset of brute force attack
● How to prevent?
○ MFA
○ Notify users of unusual activity
○ Require unpredictable usernames

61. Prevention Mechanisms
● Do not ship or deploy with any default credentials
● Have strong password requirements
○ And rotation policies
● Limit /increasingly delay failed login attempts
● Log all failures
○ Alert admins when attacks detected

62. Sample Attack - Session Timeout
● A user uses a public computer to access an application.
● Instead of selecting "logout," the user simply closes the browser tab and
walks away.
● An attacker uses the same browser an hour later, and the user is still
authenticated.

63. ZAP Tool

64. ZAP Tool
● Zed Attack Proxy
● Web security tool
● Free / Open Source Tool
● https://github.com/zaproxy/zaproxy
● Great tools for
○ Developers
○ Beginners
○ Professionals

65. How ZAP works?

66. A nice tutorial
● https://www.softwaretestinghelp.com/owasp-zap-tutorial/

67. Prisma Cloud
https://prisma.pan.dev/docs/cloud/

68. Software and Data Integrity Failures

69. Software and Data Integrity Failures
● Relates to code and infrastructure
○ That does not protect against integrity violations
● If application relies on untrusted sources’
○ Plugins
○ Libraries
○ Modules
● Insecure CI/CD pipeline can introduce potential of unauthorized access
● Attackers could potentially upload their own updates
○ To be distributed and
○ Run on previously trusted applications

70. How to Prevent
● Use digital signatures (or similar mechanisms)
○ To verify s/w / data is from the expected source
■ And not altered
● Ensure libraries and dependencies, e.g. npm / Maven
○ Are consuming trusted repositories
● Use S/W supply chain security tool
○ E.g. OWASP Dependency Check
○ OWASP CycloneDX (Currently Work In Progress)
○ Prisma Cloud Supply Chain Security
● Ensure that your CI/CD pipeline has proper:
○ Segregation,
○ Configuration,
○ And access control
● Do not send unencrypted/ unsigned serialized data to untrusted clients

71. Solarwinds Orion Attack
● Solarwinds
○ Provides system management tools
○ >30k customers - public and private orgs
● Hackers used supply chain attack
○ Inserted malicious code in Orion system
○ Distributed in updates through Sep 2019 - Mar 2020
● The malicious code creates backdoor access
○ Hackers can impersonate users and accounts

72. Solarwinds Orion Attack
● https://www.techtarget.com/whatis/feature/SolarWinds-hack-explained-Everyt
hing-you-need-to-know
● https://www.techtarget.com/searchsecurity/news/252493841/Microsoft-FireEy
e-create-kill-switch-for-SolarWinds-backdoor

73. Sample Code BinaryFormatter

74. BinaryFormatter Dangerous
● Deserialization
○ Using BinaryFormatter .NET
● Unwanted Code Execution
● Can create instance of any type on the server
● No restriction
● Any constructor
● Do not use for any user input
● https://www.meziantou.net/deserialization-can-be-dangerous.htm

75. Security Logging and Monitoring Failures

76. Security Logging and Monitoring Failures
● Detect, Escalate & respond to active breaches
○ In real time
○ Or near real time
● Always log
○ Logins
○ Failed logins
○ High value transactions
● Penetration testing tools/ scans
○ Should be able to create alerts

77. How to Prevent
● All login activities logged
● Log files are secure and cannot be deleted
○ Set append-only attribute on files
■ Attackers cannot delete their trail from logs
● Use security log analyzer
○ To detect malicious activity based on logs
○ Various Machine learning algorithms
■ Help detect anomalies
● Have incident response plan in place
○ Should be reviewed every six months/1 year
● https://www.dnsstuff.com/security-log-best-practices

78. Server Side Request Forgery

79. Server Side Request Forgery
● Web application fetches remote resource
○ Without validating user supplied URL
● Similar to CSRF
○ But all on server side

80. Sample workflow
● Ref:
https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forge
ry_Prevention_Cheat_Sheet.html

81. Example attack
● https://portswigger.net/web-security/ssrf

82. How to Prevent
● Sanitize & validate all client-supplied input data
● Enforce the URL schema, port, and destination with a positive allow list
● Disable HTTP redirections
● Do not return raw response from any URL
○ As is to the user
○ The hacker might be getting some other resource which they are not supposed to

83. A good read
● Unfortunate Reality of Insecure Libraries

84. References
● https://docs.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-
security-guide

85. Summary
● We went through all of OWASP Top 10
● Now you are closer to making your application more secure
● Security is a journey
○ Not a destination
● As a developer
○ Write more secure code
● As an architect
○ Design with security in mind
● As an organization
○ Have gatekeepers in place

86. Remember General Tips
● Always have
○ Threat modeling in place
● Keep separate time reserved
○ For security testing
○ Fixing flaws
● Keep Security of high importance
○ Throughout the organization

87. Connect With Me
● For any questions:
○ https://linkedin.com/in/coach4dev