Security misconfiguration talk

1. Security Misconfiguration
Secure ASP.NET Configuration, Password Management
Jiří Danihelka

2. Secure ASP.NET Configuration

3. OWASP Top 10 Security Risks for ASP.NET
3
 10 most common security threats
 how to avoid them when creating websites
 how to perform hacking / penetration testing

4. Security Misconfiguration
Recommendations:
 This topic is very broad and it
is hard to give a general
recommendation.
 Check your website
configuration carefully. Pay
attention to settings related
to security (e.g. session
timeout).
4
 Change default passwords
 Do not store production
credentials in the repository
 Use different credentials in
Dev and Live environments

5. Clickjacking
 Attack description:
- transparent iFrame that is controlled by user interaction
- the use can unintentionally make requests he did not want to
5

6. Custom Errors
Recommendations:
 Use custom error pages
 RemoteOnly setting disables
custom errors on localhost
6

7. Information disclosure
Recommendations:
<!-- enableVersionHeader - Remove the ASP.NET version
number from the response headers. Added security through
obscurity. -->
<httpRuntime targetFramework="4.5"
enableVersionHeader="false" />
<httpProtocol>
<customHeaders>
<!-- X-Powered-By - Remove the HTTP header for added
security and a slight performance increase. -->
<clear />
</customHeaders>
</httpProtocol>
7

8. Leaving Tracing & Debuging Enabled
 The trace feature of ASP.NET is
one of the most useful tools that
you can use to ensure application
security by debugging and
profiling your Web-based
applications.
 Unfortunately, it is also one of the
most useful tools that a hacker
can use to attack your Web-based
applications if it is left enabled in
a production environment.
8

9. Maximum URL Request Length
Recommendations:
<!-- maxRequestLength="4096" - The maximum length of the url request in kilobytes.
-->
<httpRuntime maxRequestLength="4096"/>
9

10. Password Management

11. How to properly store production passwords?

12. Store passwords in code repository?
Definitely no!
 Not all developers should
have access to production
passwords
 Problems with open-
source projects
 High risk of password
leaking (e.g. during a code
audit)
12

13. Store passwords in emails? No
 Many emails
 Hard to update passwords
 Who has the password?
 Hard to restrict spreading
13

14. Store passwords in Confluence? No
 Confluence is for
documentation
 Documentation is shared
with other parties that
should not have access
to passwords
 Does not support
different levels of access
(dev, stage, pre-release,
live)
14

15. Store passwords in Connection Strings? No
 Not all passwords are
connection strings
 Hard to protect and
retrieve later
 Sometimes have to
connect to the server
15

16. Solution: Password Management

17. Password Management
Live demo
17