This talk was presented at the 7th WCSQ World Congress for Software Quality in Lima, Perú on Wednesday, 22nd March 2017. Writing secure code certainly is not an easy endeavor. In the book titled “Writing Secure Code: Practical Strategies and Proven Techniques for Building Secure Applications in a Networked World (Developer Best Practices)” authors Howard and LeBlanc talk about the so called attacker’s advantage and the defenders dilemma and they put into perspective the fact that developers (identified as defenders) must build better quality software because attackers have the advantage. In this dilemma, software applications must be on a state of defense because attackers are out there taking advantage of any minor mistake, whereas the defender must be always vigilant, adding new features to the code, fixing issues, adding new engineers to the team. All this conditions are important when it comes to software security. Sadly, strong understanding of software security principles is not always a characteristic of most software engineers but we can’t blame them. Writing code is a complex task per se, the abstraction level required, along with choosing and/or writing the accurate algorithm and dealing with tight schedules seems to be always a common denominator and the outcome when talking to developers. This talk also includes techniques, tools and guidance that software engineers can use to perform Application Security testing during the development stage, enabling them to catch vulnerabilities at the time they are created.

1. Application Security Testing: Building
Software Resilient to Attacks
Lima, 7th WCSQ
Michael Hidalgo, March 22, 2017

2. Who Am I?
• Software Engineer based in Costa Rica
• OWASP Costa Rica Chapter Leader
• Recurrent Speaker on Application Security
conferences
• Head of Software Development Engineering
at DeepRecce, a Cybersecurity company
with offices in Costa Rica.
• Hacker looking for challenging the Status
Quo

3. Disclaimer
The opinions expressed in this presentation and on the following
slides are solely my own and not necessarily those of my
employee.
The techniques presented on this talk have the unique purpose
of teaching and creating awareness about Application Security.

4. –Michael Howard, Microsoft Senior Security Program Manager
“If your engineers know nothing about the basic security tenets,
common security defect types, basic secure design, or security
testing, there really is no reasonable chance they could produce
secure software.”

5. Why this presentation?
• According to Verizon DBIR 2016: Web
Application Attacks are the #1 Source of
Data Breaches.
Source: Verizon 2016 Data Breach Investigation Report:
https://www.verizondigitalmedia.com/blog/2016/06/verizon-dbir-2016-web-application-attacks-are-the-1-source-of-data-breaches

6. Why this presentation?
• Looking to the future : Cisco IBSG predicts
there will be 50 billion devices connected to
the Internet by 2020
Source: Cisco Internet Business Solutions Group The Internet of Things How the Next Evolution of the Internet Is Changing Everything
http://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf

7. Why this presentation?
Image source : http://www.gridshore.nl/wp-content/uploads/costofdefects.jpg

8. Why this presentation?
Source: https://consumerist.com/2011/06/14/how-hackers-stole-200000-citi-accounts-by-exploiting-basic-browser-vulnerability/

9. Why this presentation?
Source: http://www.bbc.co.uk/news/world-us-canada-38324527

10. Why this presentation?
Source: http://thehackernews.com/2017/02/iot-teddy-bear.html

11. Building Blocks Information Security

12. 1. Confidentiality
• Security concept that has to do with
protection against unauthorized information
disclosure.
• It also helps to maintain data privacy.
• It is the concept of preventing the
disclosure of information to unauthorized
parties.
• Core function is keeping secrets secret.

13. 2. Integrity
• Refers to protecting data from unauthorized
alteration.
• Is the measure of software resiliency.
• Integrity software ensure that the data that
are transmitted, processed and stored are
as accurate as the originator intended.
• It must ensure that software performs
reliably.

14. 3. Availability
• Access to the system by authorized
personnel.
• Criticality of data and it uses in the system
are essential factors to determine system’s
availability.
• Service Level Agreement (SLA) is an
instrument that can be used to explicitly
state and govern availability requirements
for business partners and clients.

15. 4. Authentication
• Process of determining the identity of a user.
• Foundational element of security.
• It ensures that only valid users are admitted.
• It is the process used to verify into a
computer system that the individual is who it
claims to be.
• Three methods are used:
• Something you know.
• Something you have.
• Something you are.

16. 5. Authorization
• Process of applying access control rules to
a user process.
• Determines whether or not a user has
access to a given object.
• Access to objects is controlled based on
the rights and privileges that are granted to
a requestor by the owner of the data or
system.
• Once we know who you are, authorization
responds to the question, What do you
have access to?

17. 6. Auditing/Logging
• Passive detective control mechanism.
• Nonrepudiation addresses the deniability of
actions taken either by a user or software
on behalf o a user.
• Auditing can be seen as a form of recording
historical events on a system.

18. Building Blocks Application Security

19. The Core Of Application Security : User can submit arbitrary input
• The end user is outside of the application’s control, and they could send
arbitrary input to the server-side application.
• The application must always treat all input as if it was damaging.
• It is important to ensure that the input data cannot be manipulated to interfere
with the application business logic.
• Most of the attacks targeting Web applications, contains crafted payloads to
trigger an event that was not considered by the application or by it’s design.
Source: The Web Application Hacker Handbook 2nd Edition, page 9

20. All Input is Evil!
URL
Form fields
GET
Parameters
POST
Payloads
HTTP
Headers
Web
Services
Cookies
External
Services
Database

21. Trusted and Untrusted Data

22. Image taken from : http://blog.prestonbailey.com/files/2010/11/Overcoming-Challenging-Obstacles.jpg
Application Security Implementation Challenges

23. Iron Triangle Constraints
• A software development project, from design to implementation, there is a
need for Schedule (time), Scope (resources) and Budget (cost).
• Resources with technical skills and knowledge are not always readily available.
• Having the need to incorpore security into the software is seen as an extra and
costly activity.
• Constraints in terms of Schedule, Scope and Budget are sometimes the
reasons why security is left behind.

24. Security as an Afterthought
• Sometimes security is being considered as an afterthought and a process that
is hard to justify as a part of the security investment.
• The value added of security into an application is not easy to show.
• End users don’t perceive security as an asset in their day to day activities.
• Addressing security vulnerabilities before a product is released is very
expensive.

25. Security versus Usability
• Traditionally, security has had a negative impact in the usability of the software.
That is, the software is seen more complex, more restrictive and less usable.
• As an example, a secure password policy might force the users to follow a
pattern including a minimum and maximum of characters, upper and lower
case and numbers.
• Sometimes when detective controls (e.g logs) are included into the system, it
leads to slowdown the process and you can find users complaining about the
security measure slowed down the operation because of the amount of time it
takes to execute a process.

26. Why the Application Security Problem is Growing?
… And why you should care.

27. Complexity of modern Software Applications and Infrastructure
Image Source: https://www.reddit.com/r/funny/comments/5q59nd/in_case_of_cyberattack

28. Because….

29. Writing Insecure Code is relatively easy.
What if there is an error
inside this function?
This code will be
executed.
Source: Writing Secure Code 2nd Edition. Michael Howard and David LeBlanc page 65

30. Overwhelming number of Javascript frameworks.
Image source: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.2mwrox3hf

31. High Dependency on Third Party Libraries

32. Why Good engineers write
bad code?
• Technical Factors: Intrinsic complexity in
underlaying technologies.
• Physiological Factors: Programmers are
humans and security errors are easy to
overlook.
• Risk Assessment Problems: It’s hard to find
a security issue in a code review if we don’t
understand what security means.

33. The proliferation of insecure Mobile Applications and API’s

34. Security is everyones job!

35. Security is everyone’s job
• Security is Holistic: Software is only as secure as the weakest link.
• Application, Host and Network needs to be secured adequately and
appropriately.
• Builders must practice Secure Engineering.
• Operations must continue architecting reasonable networks.
• Executives must understand how early investment on security design and
analysis affects their products.

36. Security must be a priority on every Software Development Team
Source: Introduction to the Microsoft Secure Development Lifecycle (SDL)
https://download.microsoft.com/download/9/3/5/935520EC-D9E2-413E-BEA7-0B865A79B18C/Introduction%20to%20the%20Microsoft%20Security%20Development%20Lifecycle%20(SDL).ppsx
Education Accountability
Administer and track security
training
Incident
Response
(MSRC)
Establish release criteria and
sign-off as part of FSR
Ongoing Process Improvements
Process
Guide product teams to meet
SDL requirements

37. An approach for Application Security Testing

38. What is Application Security Testing?
• Security Testing is different.
• It is about demonstrating that a tester can’t spoof a user’s identity.
• It is about verifying that a tester can’t tamper parameters.
• Security Testing is about proving that defensive mechanisms work correctly.
• Type of testing focused on checking that some features appear to fail.
• A security test is a method of evaluating the security of a computer system or
network by methodically validating and verifying the effectiveness of application
security controls.

39. Old Security Vulnerabilities on new Clothes!
Source: https://www.owasp.org/index.php/Top_10_2013-Top_10

40. OWASP Testing Guide : The Goodness of Open Source
This guide can be downloaded from : https://www.owasp.org/images/1/19/OTGv4.pdf

41. The OWASP Testing Framework Explained.

42. Phase 1: Before Development Begins

43. Phase 2: During Definition and Design

44. Phase 3: During Development

45. Phase 4: During Deployment

46. Phase 5: Maintenance and Operations

47. OWASP Web Application Security Testing

48. OWASP Testing Methodology

49. Reporting
1. Executive Summary
2. Test Parameters
1. Project Objective
2. Project Scope
3. Project Schedule
4. Targets
5. Limitations
3. Findings

50. Findings Template
Full access to the reporting section: https://www.owasp.org/index.php/Reporting

51. Other Resources

52. OWASP Zed Attack Proxy Project
• It is one of the world’s most popular free security tools and is actively
maintained by hundreds of international volunteers.
• It can help you automatically find security vulnerabilities in your web
applications while you are developing and testing your applications.
• Its also a great tool for experienced pentesters to use for manual security
testing.

54. OWASP ZAP

55. OWASP Code Review Guide
• Alpha Release OWASP Code Review 2.0
• It is a technical book written for those responsible for code reviews
(management, developers, security professionals).
• While security scanners are improving every day the need for manual security
code reviews still needs to have a prominent place in organizations SDLC
(Secure development life cycle) that desires good secure code in production.
Full access to the Code Review Guide here : https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

56. ISTQB: Advanced Security Tester
Full access to the Certification here : http://www.istqb.org/certification-path-root/advanced-security-tester/advanced-security-tester-contents.html

57. Book references:

58. Other references
• The Open Web Application Security Project OWASP https://www.owasp.org/
index.php/Main_Page
• Microsoft Secure Development Lifecycle https://www.microsoft.com/en-us/
sdl/
• Infosec Institute Penetration Testing Methodology and Standards http://
resources.infosecinstitute.com/penetration-testing-methodologies-and-
standards/
• ISTQB Security Tester http://www.istqb.org/certification-path-root/advanced-
security-tester.html

59. Q&A.
Michael Hidalgo
michael.hidalgo@owasp.org