- The document discusses common web application vulnerabilities like SQL injection, cross-site scripting, and cross-site request forgery. - It provides examples of vulnerable code and outlines secure coding practices to prevent these vulnerabilities, such as using parameterized queries to prevent SQL injection, encoding user input to prevent XSS, and using anti-forgery tokens to prevent CSRF. - Additional topics covered include secure password storage, configuration hardening through web.config settings, and implementation of security controls like encryption and encoding using libraries like ESAPI.

1. Secure Programming
in C#
Siddharth Bezalwar
@be_siddharth
siddharth.bezalwar@gmail.com

2. Agenda
● Common mistakes(Insecure coding practice).
● Illustrations based on OWASP Top 10 Web
vulnerabilities.
● Secure code practices.

3. Secure Coding?
Developing practice to guard against the
accidental introduction of vulnerabilities.

4. Quick Look
C #
– Simple, modern, general-purpose, object-oriented
programming language.
– Developed by Microsoft within its .NET initiative
led by Anders Hejlsberg.
– Very much based on C and C++ programming
language

5. Vulnerabilities
OWASP Top 10 2013 Vulnerabilities
– A1-Injection(SQL Injection)
– A2- Broken Authentication And Session Mgt.
(Password Storage)
– A3-Cross-site scripting
– A5-Security Misconfiguration
– A8-CSRF

6. A1-Injection(SQL Injection)
SQL injection is a code injection technique,
used to attack data-driven applications, in
which nefarious SQL statements are inserted
into an entry field for execution (e.g. to dump
the database contents to the attacker).

7. Vulnerable Code
Normal input:
SELECT * FROM ProductDB where id =' 1 ' AND name=' XYZ ' and cost=' 123 ';
Malicious input('or'='1'='1):
SELECT * FROM ProductDB where id=' 1’or'1’='1 ' AND name = ' XYZ 'or'1'='1 ' AND
cost =' 123'or'1'='1 ';

8. Incorrect Mitigation
● Client side validations.
● Blacklisting of SQL keywords
● Checking number of rows returned.

9. Secure Code
Parameterized sql query and it’s working:
• Parameters i.e. user inputs are never inserted directly into the
statement.
• A system stored procedure called sp_executesql is called with
given SQL statement and parameters.
• Parameters are treated as data instead of parsing out as a SQL
statement string.

10. Leaks or flaws in the authentication or session
management functions (e.g., exposed
accounts, passwords, session IDs) to
impersonate users. Developers frequently
build custom authentication and session
management schemes, but building these
correctly is hard.
A2- Broken Authentication and
Session Management.

11. Secure Implementation
● Do not store passwords in plain text.
● Don't attempt to implement your own hashing schemes, use strong and valid,
time proven and tested cryptography algorithms such as ASP.NET's Identity (be
aware of the low 1000 iteration count).
● For scenario's where implementation is required, use a unique salt with a high
level of entropy with each password hash. Hash with a valid hashing algorithm
such as PBKDF2 and Bcrypt with a high level of hashing rounds.
● https://cmatskas.com/-net-password-hashing-using-pbkdf2/
Password Storage:

12. Wacky Hash Functions
● md5(sha1(password))
● md5(md5(salt) + md5(password))
● sha1(sha1(password))
● sha1(str_rot13(password + salt))
● md5(sha1(md5(md5(password) +
sha1(password)) + md5(password)))

13. A3-Cross-site Scripting
Cross-site scripting (XSS) is a type of
computer security vulnerability typically found
in web applications. XSS enables attackers to
inject client-side scripts into web pages viewed
by other users. A cross-site scripting
vulnerability may be used by attackers to
bypass access controls such as the same-
origin policy.

14. Vuln. Code (Reflected)
• Sanitization(encoding) of user input is missing.
• User’s input is included in web page and treated as code
by the victim’s browser.
User Input:
<script>alert(‘Hacked’)</script>

15. Secure Implementation
● ValidateRequest="true"
– rejects the input because it includes potentially dangerous HTML characters.
On .aspx file
<%@ Page Language="C#" ValidateRequest="true" %>
● Encode HTML Output
– Server.HmlEncode(HttpServerUtility)
– HttpUtility.HtmlEncode
● Encode URL Output
– Server.UrlEncode(HttpServerUtility)
– HttpUtility.UrlEncode

16. Secure Implementation contd.
To safely allow restricted HTML input
● Disable ASP.NET request validation by the adding the
ValidateRequest="false" attribute to the @ Page directive.
● Encode the string input with the HtmlEncode method.
● Use a StringBuilder and call its Replace method to selectively
remove the encoding on the HTML elements that you want to permit

17. Secure Implementation Contd.
HTML-encoding of user input.

18. Vuln. Code (DOM)
HTMLcontent is set without validation and sanitization.

19. Secure Code
Creates text node and appends it to the DOM element.

20. • HTML escape then JavaScript escape in HTML subcontext.
<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>
• URL escape then JavaScript escape in URL attribute subcontext.
<%=Encoder.encodeForJS(Encoder.encodeForURL(userRelativePath))%>
• JavaScript escape in HTML and CSS attribute context.
For HTML attribute ,escape the untrusted input and then set the attribute of DOM
element.
<%=Encoder.encodeForJS(untrustedData)%>
For CSS attribute
document.body.style.backgroundImage = "url(<
%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>)"
Secure Implementation
Use ESAPI ( https://www.owasp.org/index.php/ESAPI )

21. A5-Security Misconfiguration
Security Misconfiguration arises when Security
settings are defined, implemented, and
maintained as defaults. Good security requires
a secure configuration defined and deployed
for the application, web server, database
server, and platform. It is equally important to
have the software up to date.

22. Web.Config File
Debug settings:
<compilation debug="false" targetFramework="4.5"/>
Request Processing:
<httpRuntime enableVersionHeader="false" requestValidationMode="4.0" />
Cookie Settings:
<httpCookies httpOnlyCookies="true" requireSSL="true" lockItem="true"/>
Trace Settings:
<trace enabled="false"/>
Web Application settings (<system.web>)

23. Directory Browsing Setting:
<directoryBrowse enabled="false"/>
Web server settings (<system.webServer>)
Custom Header Setting:
The <customHeaders> element of the <httpProtocol> element specifies
custom HTTP headers
Web.Config File

24. <httpProtocol>
<customHeaders>
<remove name="Access-Control-Allow-Origin"/>
<add name="Access-Control-Allow-Origin" value="http://domain.com"/>
<remove name="X-Powered-By"/>
<remove name="X-Frame-Options"/>
<add name="X-Frame-Options" value="SAMEORIGIN"/>
<remove name="X-Content-Type-Options"/>
<add name="X-Content-Type-Options" value="nosniff"/>
<remove name="X-XSS-Protection"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Strict-Transport-Security"/>
<add name="X-Strict-Transport-Security" value="max-age=15768000; includeSubDomains"/>
<remove name="X-Content-Security-Policy"/>
<add name="X-Content-Security-Policy" value="default-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline
fonts.googleapis.com; font-src 'self' fonts.gstatic.com;"/>
<remove name="X-WebKit-CSP"/>
<add name="X-WebKit-CSP" value="default-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'
fonts.googleapis.com; font-src 'self' fonts.gstatic.com;"/>
</customHeaders>
</httpProtocol>

25. A8- Cross-site request forgery
● Cross-Site Request Forgery (CSRF) is an
attack that forces an end user to execute
unwanted actions on a web application in
which they're currently authenticated. CSRF
attacks specifically target state-changing
requests, not theft of data, since the attacker
has no way to see the response to the forged
request.

26. Wrong Assumptions
● Assuming that SSL/TLS will thwart CSRF attacks
just because the cookie is marked "Secure"
and/or "HTTPOnly"
● Referer header verification as the only protection
● Any CSRF protection is null and void given the
presence of XSS
● Cookie double-submission when the cookie
utilized is the session cookie.

27. Secure Implementation
Use Anti-Forgery Tokens
1.Generate the security token (or grab it from the session state) and send the token as a
session cookie (again, managed in the session state, unique per session) as well as within
a hidden value in each form.
2.Once the user submits the form, validate the token stored in the session state against
the token included in the submitted form value. On failure, disregard form.

28. Rendering token as a hidden field on aspx page.
Secure Implementation

29. Secure Implementation
Method for generating random token and response handling

30. Secure Implementation
Generating token and saving it in session

31. Secure Implementation
Validating token received from request against the token saved in session
state

32. Thank you!!!