This presentation describes a possible approach to follow to take care of the security of legacy code through the use of various OWASP projects.

1. Securing your web applications: a
pragmatic approach
Antonio Parata - an.parata@reply.it
Roma 12/12/2014

2. Who am I?
- Head of Reply Communication Valley R&D group
- Passionate about functional programming (F#)
and occasional tools developer
(http://nebula.tools)
- Passionate about software security
- Board member of OWASP Italy (Co-Author of
OWASP Testing Guide v2 e v3)

3. Introduction
What does legacy application mean?
- An application difficult to modify/maintain
- An application lacking documentation
- An application writtent “a long time ago” (… in cobol)
“…to me, legacy code is simply code without tests.”
Michael C. Feathers author of Working Effectively With Legacy Code

4. Introduction
Why talk about legacy application?
A pragmatic approach
– The goal is securing an application and not learning
how to compromise its security
– You have to know the most common vulnerabilities
anyway

5. Approach
1. Perform a security assessment activity in
order to evaluate the current state of security
2. Start to focus your activities in order to
improve the application security.
- Don’t limit yourself to fixing of the vulnerabilities
reported in the security assessment report
3. Verify your progress

6. Approach
Which activity is advisable to be first executed?
- Code Inspection
- Security Testing
- Penetration Test
Ref.Capers Jones - Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies (McGraw-Hill, 2010)

7. OWASP Top Ten
Useful to have an idea of
the most common threats
Streamlined enough to be
easly read even from
security inexperts.

8. OWASP - Proactive Controls for
Developers
Provides a Top Ten of the most important
security controls that must be considered for the
security of the application

9. OWASP - Proactive Controls for
Developers - Parameterize Queries
$stmt = $dbh->prepare("update users set
email=:new_email where id=:user_id");
$stmt->bindParam(':new_email', $email);
$stmt->bindParam(':user_id', $id);

10. OWASP - Proactive Controls for
Developers – Encode Data
It starts with a < to end with a

11. OWASP - Proactive Controls for
Developers – Encode Data
The majority of modern Web Development Frameworks includes preset
encoding capability.
If your are in doubt:
Ruby on Rails
– http://api.rubyonrails.org/classes/ERB/Util.html
Reform Project
– Java, .NET v1/v2, PHP, Python, Perl, JavaScript, Classic ASP
– https://www.owasp.org/index.php/Category:OWASP_Encoding_Project
ESAPI
– PHP.NET, Python, Classic ASP, Cold Fusion
– https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
.NET AntiXSS Library (v4.3 NuGet released June 2, 2014)
– http://www.nuget.org/packages/AntiXss/

12. OWASP - Proactive Controls for
Developers – Validate All Inputs
In most cases the expected input has a well
defined format…
…ensure that the format is correclty applied!
Approachs:
Whitelist  what is not allowed is refused
Blacklist what is malicious is blocked

13. OWASP - Proactive Controls for Developers –
Implement Appropriate Access Controls
Various consolidated models exist: RBAC, ACL
Access Control code can be very complex to
implement. Some suggestions:
All the requests must pass through the access
control code:
- Deny by default
- Don't reinvent the wheel

14. OWASP - Proactive Controls for Developers –
Establish Identity and Authentication Controls
Authentication is the process that verifies that an
entity is really what it says it is.
Once authenticated, a session is usually created
Make sure that
- All the passwords are salted and stored in a safe way (eg.
By using the BCrypt alghorithm)
- The session token is appropriately protected and not
predictable (tipically it is enough to use the features of
the following framework)

15. OWASP - Proactive Controls for Developers –
Protect Data and Privacy
All sensitive data have to be sent through a
secure channel
- Using HTTPS for sensitive data transmission
- Using antitampering mechanism to make sure
that data can’t be modified arbitrarily by the
user.

16. OWASP - Proactive Controls for Developers –
Implementing Loggin and Intrusion Detection
Logging is not performed only during debugging phase
Make sure that:
- Log every single sensitive action (login, password change,…)
- Store log in a secure place
- Don’t include sensitive information inside log content
(password, session token, …)
Ensure that logs are analyzed by a security analyst or by a
security system and that appropriate actions are taken if
something happens.

17. OWASP - Proactive Controls for Developers – Leverage
Security Features of Frameworks and Security Libraries
According to the programming language used,
there could be different frameworks that provide
a baseline for implementing security features.
Those frameworks are tipically well writtent and
with a stable code base.
But make sure that you are always updated with
new unknown vulnerabilities

18. OWASP - Proactive Controls for Developers – Include
Security - Specific Requirements
It is never too late to consider new security
requirements
Consider:
1. Security Features and Functions
2. Business Logic Abuse Cases
3. Data Classification and Privacy Requirements

19. OWASP - Proactive Controls for Developers – Design
and Architect Security In
In Legacy application it is difficult to change the
architecture, consider however the following
points:
- Attack surface
- Used frameworks
- Specific vulneabilities that are more common
in the language used and/or in the tools used

20. Trust but verify
OWASP - Proactive Controls for Developers is a
guide that helps developers to secure their
applications code
But you have to be sure that the written code is
really secure
OWASP Application Security Verification
Standard (ASVS)

21. OWASP - ASVS
“The first aim of the OWASP Application Security
Verification Standard (ASVS) Project is to
normalize the range in the coverage and the
level of rigor available in the market when it
comes to performing Web application security
verification using a commercially-workable open
standard.”https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

22. OWASP - ASVS

23. OWASP – ASVS Requirements
V2: Authentication Verification Requirements
V3: Session Management Verification Requirements
V4: Access Control Verification Requirements
V5: Malicious Input Handling Verification Requirements
V7: Cryptography at Rest Verification Requirements
V8: Error Handling and Logging Verification Requirements
V9: Data Protection Verification Requirements
V10: Communications Security Verification Requirements
V11: HTTP Security Verification Requirements
V13: Malicious Controls Verification Requirements
V15: Business Logic Verification Requirements
V16: Files and Resources Verification Requirements
V17: Mobile Verification Requirements

24. Conclusions
1. Verify the current state of your
application security, performing:
- Security Testing
- Code Inspection
2. Apply effective security controls
in your code (Proactive Controls)
3. Verify that the written code is
really secure (ASVS)
4. Repeat the process from step 1
on a regular basis.

25. Q&A