AppSec DC 2019 ASVS 4.0 Final

Securing Applications with OWASP
Application Security Verification

Standard 4.0
Andrew van der Stock
September 2019
Day 1
TM
GLOBAL APPSEC DC
About OWASP
• The Open Web Application Security Project
(OWASP) is a 501(c)(3) worldwide not-for-
profit charitable organization focused on
improving the security of software.
• Our mission is to make software security
visible, so that individuals and organizations
worldwide can make informed decisions
about true software security risks.
• Everyone is free to participate in OWASP and
all of our materials are available under a free
and open software license. You'll find
everything about OWASP linked from our wiki
and current information on our OWASP Blog.
• https://owasp.org
OWASP GLOBAL APPSEC - DC

• Senior Principal Consultant,
Synopsys
• OWASP Board member 2015-2018

• OWASP ASVS co-lead
• OWASP Top 10 co-lead
• OWASP Developer Guide 2.0 lead
• Family, cats, WRC nut

Who are you?
• Name
• Role
• Serial number (joking)
• What are your biggest

challenges?
• What do you want out of the
course?
This Photo by Unknown Author is licensed under CC BY-NC-ND

Agenda
TM
GLOBAL APPSEC DC
Agenda Day 1
Morning Afternoon
• V4 Access Control • Introductions
• V4 Access Control Lab • About ASVS
• Incorporating ASVS into your
development lifecycle
• V5 Validation and Encoding
• V1 Architecture
• V5 Validation and Encoding Lab • V2 Authentication
(tbc)
• V3 Session Management
• V2 and V3 Lab
Agenda Day 2
Morning Afternoon
• V8 Data Protection • V5 Validation and Encoding Lab
• V8 Data Protection Lab (cont)
• V9 Communications Security • V6 Cryptography at rest

• V9 Communications Security Lab • V6 Cryptography Lab
• V10 Malicious Code • V7 Logging and Error Handling

• V10 Malicious Code Lab • V8 Logging lab

Agenda Day 3
Morning Afternoon
• V13 API and Web Services • V11 Business Logic Flaws
• V13 API Lab • V11 Business Logic Flaws Lab
• V14 Configuration • V12 Files and Resources

• V14 Configuration Lab • V12 Files and Resource Lab
• Secure Code Warrior Tournament
• References and Wrap Up

Thanks Secure Code Warrior for the labs!

OWASP Application Security
Verification Standard 4.0
Web Application Technical Security Controls, Unleashed!
TM
GLOBAL APPSEC DC
What is the Application Security Verification
Standard?
• First application security standard by
developers, for developers
• Each item is a single concept

• Each item is testable, some more than
others
• Completely open source and forkable
• Can be used in many ways
• Adopted by many governments, large

corporations, secure supply chain
procurement agreements, and
referenced by Relevant standards
Why not just use the OWASP Top 10?
• Awareness only
• Insufficient for secure software
• Contains ~ 50 CWEs and categories
(not 10)
• Not written for developers
• Not easily testable
• Difficult to comply
• Whack a mole!
• Doesn’t tell you what to do, but
rather what not to do. This Photo by Unknown Author is licensed under CC BY-NC-ND
• More than 1100 “do not do X” CWEs

Developers are security folks
• DevSecOps means no more

penetration tests at the end
• Let’s make sure the system is
tested every single build
• Work with security folks to build
security in
This Photo by Unknown Author is licensed under CC BY-SA

Security folks are developers
• Learn to code
• Use the same tool chain
• The future is not

• Test only at the end
• Two-four week engagements
• Low business impact
• Highly technical
This Photo by Unknown Author is licensed under CC BY-SA • PDF reports

Bringing everyone together
• Business
• Scrum folks
• Developers
• Security
• Testers
• DevOps

Level 1: Just basics - Easily Automated
• Level 1 contains 136 controls
• Far better than the OWASP Top 10

• Minimum acceptable assurance
• Level 1 insufficient to build a
secure application
• Easy to automate using tools

Level 2: Recommended Level
• Level 2 contains 267 controls
• Some controls are one-time activities

• Have a secure SDLC
• Use source code revision control
• Use a defect tracker
• Use repeatable, secure deployment
• Includes secure SDLC and architecture

This Photo by Unknown Author is licensed under CC BY-SA-NC • Most can be unit and / or integration
tested

Level 3: For apps that can kill you or destroy
the economy
• Level 3 contains all 286 controls,
suitable for:
• Medical applications and devices
• Above level 1 car automation
• Operational technology (OT – power,
water, sewage, chemical plants,
nuclear power stations, etc)
• Command and control software
• Financial applications that could
significantly ruin the planet’s
economy
• Level of assurance is maximum
• Level of paranoia is high

Not every item in ASVS is in this training
• ASVS contains nearly 300 items • Focus:

• Developer focus
• OWASP Top 10 2017 ~ 50 items • Testing focus
• PCI DSS 3.2.1 ~ 10 items • Secure code review focus
• Penetration tester focus
• DevOps focus in V1 and V14
• We can’t do them all in three
days • Not focus:
• Networking
• Infrastructure

Adopting ASVS within your
SDLC
TM
GLOBAL APPSEC DC
Olden days vs new days
Waterfall (and some Wagile) Today’s agile (and some Wagile)

• Analyze Business Requirements • No requirements as business sits with
• High level design the development team (hah!)
• Detailed design • Planning Sprints replace HLD and DD
• Coding • Write some tests, coding, close ticket
• Testing • Push to prod 1-100 times a day
• QA • Little to no documentation
• * Penetration test if you were unlucky
• Production • Can’t really do security tests of each
build
• Updates every 18-36 months

Planning in security in agile
Planning spike
• You Are Gonna Need It (YAGNI) Retrospectives User stories
• Developers are engineers

• Building secure software
•
Use cases with
Design for security Peer reviews

constraints
• Protect
• Detect
• Resilient Integration tests Abuse cases
TDD - Unit tests

Threat modelling 101
• Threats • Abuse cases

• Components • Hostile user stories
• Communication pathways • Functional security features
• Trust boundaries • Non-functional security features
• Processing • Web threats (no motivation)
• Data stores
• Users

Three Key Questions
• How do we reduce the number of security

vulnerabilities in our applications?
• How do we reduce the time and resources required
to perform risk analysis and threat modeling?
• How do we measure, view and respond to
application security risks?

OWASP Cornucopia
• Aligned with web app risks
• Let’s play the game
• Can download for free

• Can buy from OWASP
Merchandising Store

Elevation of privilege
• Aligned with Microsoft SDL
• Let’s play the game
• Can buy from Microsoft

• Can download and print

Using ASVS to help with unit tests
• Write unit tests to validate your

application every build
• Allows penetration testers to

concentrate on difficult to
automate tests, such as business
logic flaws, access control issues,
and things you forgot in the unit
tests

Using ASVS to help with integration tests
• End to end testing is critical

• Replicate penetration tests
• Works every build
• Selenium
• Postman
• Protractor
• Robot Framework

How to fork and use ASVS
Let’s fork
TM
GLOBAL APPSEC DC
Lab: Fork ASVS
• Install GitHub Desktop

• Clone https://github.com/OWASP/ASVS/
• You now have a forked copy

Keep up to date with upstream
• git remote add upstream

https://github.com/OWASP/ASVS
• git fetch upstream
• git checkout master
• git merge upstream/master

Contribute back
• Create pull requests (either in Github itself, or via CLI)

Modifying the ASVS
• It’s in Markdown. You can change anything with a text editor
• Feel free to change the text for your local requirements

• Feel free to delete items.
• Don’t renumber items.
• Add your local items as “x.y.50” and on up

Translating the ASVS
• Create a fork in Github
• Create your local language directory (pt_br, jp, it)

• Translate one chapter and item at a time
• Spell and grammar check your translation
• Confirm that the English and your translation mean the same thing
• Create a pull request to have your translation added to the official

repo

Baffled? We are too. Ask questions
• There’s a lot of items in the ASVS.

• If it’s confusing to you in your language or you can’t translate it, it’s likely to
be confusing in English as well
• If it’s bizarro control, create a GitHub issue and we’ll address it in the master
• Ask for explanations on OWASP Slack

Lab Setup
TM
GLOBAL APPSEC DC
Secure Code Warrior Setup
• Gaining access to the lab
• Pick a language
• Let’s pick a lab together
• Create a fix
• Test the result

Architecture
Design security in
TM
GLOBAL APPSEC DC
What is Security Architecture
• Architectural principles
• Secure design patterns
• Shared secure component
design and re-use
• Expects ~25% architecture
change every 3-5 years
• Addresses current and future
threats
This Photo by Unknown Author is licensed under CC BY-ND

Benefits of a security architecture
• Stands the test of time

• Reduces refactoring costs
• Aligns business risk with costs
• Reduces losses from breaches
• Protects financials and
shareholder value
• Privacy and data protection
• Reduces regulatory risks
• Reduces reputation losses This Photo by Unknown Author is licensed under CC BY-SA

Security architecture goals
• Secure by default implementation
• Re-use secure components
• Segmentation and loose coupling
• Confidentiality
• Integrity
• Availability
• Non-repudiation
• Detection and response
• Resilience
• Secure by default configuration This Photo by Unknown Author is licensed under CC BY-SA
• Testable security

Some past breaches
• Office of Personnel Management –
the personnel record, background
checks, and fingerprints of every
Federal Government employee and
contractor, including spies, law
enforcement agents, judges, and
many senior heads of departments.
• Equifax 2017 – 147.9 million records,

including credit history, SSN, identity
proofing, driver’s licenses and more
• Yahoo 2013 – 3 billion passwords

1.1.1 Secure SDLC
• Verify the use of a secure software • Recommended solutions
development lifecycle that addresses • Pick a secure SDLC
security in all stages of development. • Create a maturity action plan to adopt it
• Rationale systemically over time
• Educate developers and business on
• Just like scalability and performance, secure SDLC
security has to be built in
• Secure SDLC happens continuously • Architecture Review
• Everyone is a part of the SDLC • Ensure that a SDLC is defined
• RIP “security sits to the side”. You will not • Ensure that the SDLC has security
be missed activities throughout all phases
• Relevant standards • Ensure that developers are trained in
secure SDLC techniques
• OWASP Proactive Controls C1 Define
Security Requirements
• NIST 800-53 SA-3 (High priority)

1.1.2 Use threat modelling
• Verify the use of threat modeling for • Recommended solutions
every design change or sprint • Attend threat modelling talks at AppSec
planning to identify threats, plan for DC
countermeasures, facilitate • Learn how to perform threat models
appropriate risk responses, and guide • Document threat models in Confluence
security testing. or similar
• Rationale • Create and update threat models with
new tickets
• Abuse cases don’t generate themselves
• Threat modelling helps understand how • Architecture Review
critical data assets can be attacked • Review threat models for completeness
• Understand the trust boundaries of all • Review abuse cases and constraints
your components • Ensure that there are unit and integration
• Relevant standards tests present related to threat models
• Choose a sampling of these to determine
• OWASP Proactive Controls C1 if they could prevent or detect the
• NIST 800-53 SA-17 documented threats

1.1.3 Security constraints for all
• 1.1.3 Verify that all user stories and • Recommended solutions
features contain functional security • Write security constraints and abuse
constraints, such as "As a user, I cases for each user story, task or issue
should be able to view and edit my • “As a user, I should not be able to view or
profile. I should not be able to view or change anyone else’s profile”
edit anyone else's profile“ • “As an administrator, I should be able to
view and change anyone’s profile, but such
viewing and changes should be auditable”
• Rationale
• Abuse cases and security constraints are • Architecture Review
usually functional requirements • Review user stories for presence of abuse
• Functional requirements are testable cases and constraints
• Review tickets to determine if constraints
• Relevant standards were considered during implementation
• OWASP Top 10 • Review the implementation to determine
• OWASP Proactive Controls C1 if the constraints were coded
• NIST 800-53 SA-17 • Review test cases to determine if the
constraints are tested

1.1.4 Documented trust boundaries
• Verify documentation and justification of • Recommended solutions
all the application's trust boundaries, • Create a list of all components
components, and significant data flows. • Place in an architecture diagram
• Rationale • Document data sources
• Understand who can send you malicious • Document users of data sources
data • Document data sinks
• Understand who might consume malicious • Document consumers of data sinks
data
• Understand the sorts of controls necessary • Architecture Review
at these boundaries (authentication, access • Review if the documented design includes
control, input validation, output trust boundaries
• Relevant standards • Sample the trust boundaries to determine if
they are present in the code or
• OWASP Top 10 configuration
• OWASP Proactive Controls C1 • Sample code or interview to identify if the
• NIST 800-53 SA-17 trust boundaries are up to date

1.1.5 High level architecture
• Verify definition and security • Recommended solutions
analysis of the application's high- • If waterfall, BDUF
level architecture and all • Agile avoids BDUF, document your
connected remote services. architecture as you go
• Rationale • Ensure the architecture is updated as
code and configuration is updated
• Conceptual integrity
• Reduce re-work due to dead ends • Architecture Review
• Understand security boundaries • Review architecture and design
• Document architectural assumptions documentation
• Sample the documentation to ensure
• Relevant standards it is up to date
• OWASP Proactive Controls C1 • Review the documentation to
• NIST 800-53 SA-17 determine if it has sufficient depth
and accurately describes the code

1.1.6 Economy of design
• Verify implementation of • Recommended solutions
centralized, simple (economy of • Review code for any duplicated
design), vetted, secure, and mechanisms (e.g. authentication,
reusable security controls to avoid data)
duplicate, missing, ineffective, or • Refactor to use the best one
insecure controls. • Architecture Review
• Rationale • Review the application for any
• Re-use saves time and money duplicated security mechanisms in
authentication, session management,
• Fewer components requires less access control, input validation,
verification output encoding, cryptography,
• Less code == less bugs logging, and so on
• Relevant standards
• OWASP Proactive Controls C2
• NIST 800-53 SA-17

1.1.7 Uses a secure coding checklist
• Verify availability of a secure • Recommended solutions
coding checklist, security • Use OWASP Proactive Controls if just
requirements, guideline, or policy starting
to all developers and testers. • Use ASVS L1 and build up to L2 over
time
• Rationale • Include with peer code reviews and
• You don’t know what you don’t know retrospectives
• Reduces costs and re-work
• Architecture Review
• Reduces whack-a-mole security
• Establish if a secure coding checklist
• Relevant standards exists
• OWASP Proactive Controls C1 • Review if developers use it
• NIST 800-53 SA-17
1.8.1 Classify data
• Verify that all sensitive data is • Recommended solutions
identified and classified into • Use enterprise’s classification policy
protection levels. • If none exists, review ISO 27002 or the
• Rationale DHS Cyber Risk Framework
• Create one
• Don’t over classify • Label data, preferably with one of three
• Don’t under classify “public, private, sensitive”
• No point spending money • Decide on classification data protection
• Relevant standards requirements. Even public has integrity
and (transmission) confidentiality
• OWASP Proactive Controls C1 requirements
• NIST 800-53 SA-17
• Ensure there is a classification / data
protection policy
• Sample if data has been labelled and
protected

1.8.2 Define protection requirements
• Verify that all protection levels have an • Recommended solutions
associated set of protection requirements, • Prepare data protection policies for public,
such as encryption requirements, integrity private and sensitive labels (or similar)
requirements, retention, privacy and other • Review app architecture for data of this type
confidentiality requirements, and that these • Create a standard reference implementation to
are applied in the architecture. satisfy these types, building on each one
• Rationale • Document the results to encourage re-use
• Not classifying at all places you at automatic • Architecture Review
“High” risk • Ensure that data protection requirements have
• Underclassifying will lead to under protected been defined
data • Review a sample of data to ensure that these
• Overclassifying will lead to unnecessary have been implemented
additional unnecessary expenses, and possibly
slow down the system
• NIST 800-53 SA-17

1.10.1 Use source code control
• Verify that a source code control system is • Recommended solutions
in use, with procedures to ensure that • Github
check-ins are accompanied by issues or • Gitlab (on-prem/cloud)
change tickets. The source code control • Bitbucket
system should have access control and
identifiable users to allow traceability of • Architecture Review
any changes. • Review to see if source code control is in
place
• Rationale
• Enables collaboration and peer review
• Ensures flow control, not all can push to
master
• Allows automation
• NIST 800-53 SA-17

1.11.1 Document your design
• Verify the definition and • Recommended solutions
documentation of all application • Use a wiki (GitHub, Confluence, etc) to
components in terms of the business document as you go
or security functions they provide. • Make sure check-in checklists include a
mandatory documentation update check
• Rationale • Use OpenAPI (Swagger) to produce API
• Increased costs documentation
• Lack of conceptual integrity • Use JavaDoc (or similar) to produce up to
• Increased refactoring date code documentation
• Complete rewrite • Architecture Review
• Relevant standards • Check that documentation is present,
• OWASP Proactive Controls C1 and up to date
• NIST 800-53 SA-17 • Sample some of the documentation to
ensure that it matches the current state
of the build

1.14.1 Loosely couple your architecture
• Verify the segregation of • Recommended solutions
components of differing trust levels • Design each component or API to
through well-defined security stand alone
controls, firewall rules, API • Design for maximal re-use
gateways, reverse proxies, cloud- • If coupling is necessary, minimize
based security groups, or similar coupling complexity
mechanisms. • Architecture Review
• Rationale • Review components for tight coupling
• Layered security approach • If many objects are tied together
• You want attackers to make noise, so consider if refactoring might make
easier to detect sense
• NIST 800-53 SA-17

1.14.5 Sandbox and containerize
• Verify that application deployments • Recommended solutions
adequately sandbox, containerize and/or • Containerize as many elements as possible
isolate at the network level to delay and • Make each container locally stateless
deter attackers from attacking other • For large scale backends (DBMS, etc)
applications, especially when they are consider sharding and scale out
performing sensitive or dangerous actions
such as deserialization. • Architecture Review
• Review if sandboxing is in place
• Rationale • Ensure that the design is containerized
• Attackers use large attack surface to find
additional exploits
• Attackers want to move laterally
• Attackers want persistence on
compromised assets
• NIST 800-53 SA-17

Labs
• Let’s create a threat model together
“Sample call out

quote design for
highlighting a
particular point in
your bullets”

Authentication
TM
GLOBAL APPSEC DC
What is authentication?
If your name isn't down, you

aren't coming in!
These are the keys the house.

Incredibly important, make life
miserable if you lose them and yet
so many struggle with keeping
their keys secure.

Some past breaches
Have I been Pwned has 8,465,989,585
breached credentials (more than 1 for every
single person on the planet)
• TransUnion HK “secure questions”
• 7-Elevent 7pay password reset flaw
• Chegg weak passwords on 40 million
users (unsalted MD5)
• MyFitnessPal breach 150 m users with
SHA1 passwords
• Fortigate VPN magic backdoor

Poor Legacy Advice
We need to help create frictionless security.
A key part of that journey is about user
credentials.
• Bill Burr had advised users to change

their password every 90 days
• to muddle up words by adding capital
letters, numbers and symbols
Mr Burr now acknowledges that his 2003

manual was "barking up the wrong tree".

1.2.1 Low privilege service accounts
• Verify the use of unique or special • Recommended solutions
low-privilege operating system • Use a low privilege account
accounts for all application • Unit Tests
components, services, and servers.
• Try to execute a privileged operation,
• Rationale such as drop table or similar – should fail
• Allows complete compromise of all data • Architecture Review
• May allow control of the service • Ensure there is a policy around the
• Allows (sometimes) lateral movement creation, maintenance and monitoring of
• Relevant standards service accounts
• Sample one or two service accounts to
• OWASP Top 10 A2 determine if this policy is in place and
• OWASP Proactive Controls C6 effective
• NIST 800-63 x.x.x • Ensure service accounts are not default
• PCI DSS 6.5.10 accounts and unique to the application or
• NIST 800-53 AC-2 service

2.1.1 Sufficiently long passphrases
• Verify that user set passwords are • Recommended solutions
at least 12 characters in length. • Prevent less than 12-character
• Rationale passwords
• Short passwords are trivially
recovered • Unit Tests
• Short passwords are typically re-used • AuthenticationService >
• Encourages adoption of passphrases setNewPassword
– or even better, password managers • fails when password length < 12
• Relevant standards • passes when password length >= 12
• OWASP Top 10 A2
• OWASP Proactive Controls C6 • End to end integration tests
• NIST 800-63 x.x.x • Insert < 11 character password, should
fail
• PCI DSS 6.5.10 • >= 12 character password, should pass
• NIST 800-53 AC-2
2.1.10 No periodic changes
• Verify that there are no periodic credential • Recommended solutions
rotation or password history requirements. • Remove periodic change functionality
• Rationale • Implement breached password change
functionality
• This has NEVER worked
• If in enterprise space, provide an API for HR or
• Comes from 1979 paper on password cracking link to ADFS for employee parental leave,
times on a PDP 11 sabbatical, retirement and separation reasons.
• You cannot change passwords fast enough today
• Causes weak passwords and patterns • Unit Tests
• Passwords on post it notes • Review tests for periodic enforced changes - fail
• Relevant standards • End to end integration tests
• OWASP Top 10 A2 • Review for periodic enforced changes - fail
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.1.11 Permit password managers
• Verify that "paste" functionality, browser • Recommended solutions
password helpers, and external password • Remove paste restrictions if implemented
managers are permitted. • Wrap username + password input fields in
• Rationale <form> elements. Use unique element IDs for
each input field
• Improve customer experience • Consider implementing biometric authentication
• Strong random passwords cannot be cracked (FaceID, Fingerprint scans, etc) on mobile
today or any time in the next five years applications to unlock a JWT or Oauth token,
• Password managers are our best hope against eliminating usernames and passwords entry
credential stuffing completely
• Consider integrating with common password
• Relevant standards managers on mobile platforms
• OWASP Top 10 A2
• Unit Tests
• NIST 800-63 x.x.x • Not applicable
• PCI DSS 6.5.10 • End to end integration tests
• NIST 800-53 AC-2 • Use “Paste” functionality in web and mobile test
suites to paste in invalid and valid usernames
and passwords

2.1.12 Allow user to reveal password
• Verify that the user can choose to • Recommended solutions
either temporarily view the entire • Use a reveal widget on web pages
masked password, or temporarily view • Automatically hide after x number of
the last typed character of the seconds, say 10 or so
password on platforms that do not • Use default password field on mobile
have this as native functionality. platforms
• Rationale • Unit Tests
• Improve customer experience • Not applicable
• Reduce soft lockouts • End to end integration tests
• Relevant standards • Test that reveal password function
• OWASP Top 10 A2 reveals the field and hides it after a short
duration
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.1.2 No upper limit on password length
• Verify that passwords 64 characters • Recommended solutions
or longer are permitted. • Hash + salt passwords
• Rationale • Don’t worry about length
• There is no technical reason why not • Unit Tests
• Only a small percentage will use long • Test for 63, 64, 128 and 2k passwords
pw • All should work
• Hashed passwords always take fixed
storage lengths • End to end integration tests
• Relevant standards • Test for 63, 64, 128 and 2k passwords
• All should work
• OWASP Top 10 A2
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2
2.1.4 が大好き.
• Verify that Unicode characters are • Recommended solutions
permitted in passwords. A single Unicode • Remove or don’t implement password
code point is considered a character, so complexity validators
12 emoji or 64 kanji characters should be • Unit Tests
valid and permitted.
• Test that Unicode and emoji passphrases
• Rationale and passwords work
• Unicode and Emoji is generally not in any • Test 0, 11, 12, 13, 64 code point passwords
password lists
• CX will be awesome • End to end integration tests
• English is spoken by only 1.5 billion people • Test that Unicode and emoji passphrases
and passwords work
• Relevant standards • Test 0, 11, 12, 13, 64 code point passwords
• OWASP Top 10 A2
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.1.5 Users must be able to change
credentials
• Verify users can change their • Recommended solutions
password. • Implement a password change
feature
• Rationale
• Well, duh. • Unit Tests
• Test password change
• Relevant standards • Includes old password, new and
• OWASP Top 10 A2 confirm - pass
• OWASP Proactive Controls C6 • Missing old password – fail
• NIST 800-63 x.x.x • Missing new or confirm – fail
• PCI DSS 6.5.10 • Mismatch new or confirm - fail
• NIST 800-53 AC-2 • End to end integration tests
• Validate that users change password
functionality per unit tests

2.1.6 Verify the old password
• Verify that password change • Recommended solutions
functionality requires the user's • When changing passwords, ensure
current and new password. that the old password is the actual
old password
• Rationale
• Prevents attackers abusing password • Unit Tests
change function • User change password
• Confirms user identity (to a degree) • Missing old password - fail
• Wrong old password - fail
• Relevant standards • Correct old password - pass
• OWASP Top 10 A2
• NIST 800-63 x.x.x • User change password
• Missing old password - fail
• PCI DSS 6.5.10 • Wrong old password - fail
• NIST 800-53 AC-2 • Correct old password - pass

2.1.7 Breached password detection
• Verify that passwords submitted during account registration, • Recommended solutions
login, and password change are checked against a set of • Use a local or remote breached password check
breached passwords either locally (such as the top 1,000 or • When using a remote API, make sure it’s zero knowledge
10,000 most common passwords which match the system's
password policy) or using an external API. If using an API a • Update local breach lists regularly from SecLists
zero knowledge proof or other mechanism should be used to • Unit Tests
ensure that the plain text password is not sent or used in
verifying the breach status of the password. If the password • Test a known breached password (“Password1!”)
is breached, the application must require the user to set a • Test a known safe password
new non-breached password.
• End to end integration tests
• Rationale • During login
• We have 8 billion of your usernames + passwords already • Generating random initial passwords
• Let’s not use those again • Enrolment – set initial password
• Relevant standards • Credential recovery – set replacement password
• OWASP Top 10 A2 • User or admin change password – set new password
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.1.9 No composition rules
• Verify that there are no password • Recommended solutions
composition rules limiting the type of • Eliminate composition rules
characters permitted. There should be no • Enforce length rules
requirement for upper or lower case or
numbers or special characters. • Unit Tests
• Test passwords with all lower case or all
• Rationale upper case or all numbers
• THEY HAVE NEVER EVER WORKED
• Even the 1979 paper that led to • End to end integration tests
composition rules thought they were weak • Test passphrases consisting only of lower
case letters
• OWASP Top 10 A2
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.2.1 Authentication anti-automation
• Verify that anti-automation controls are effective at • Recommended solutions
mitigating breached credential testing, brute force, and • OWASP Automated Threats to Web Applications
account lockout attacks. Such controls include blocking the • Use features of WAFs and Web Service Gateways
most common breached passwords, soft lockouts, rate
limiting, CAPTCHA, ever increasing delays between attempts, • Build in anti-automation countermeasures
IP address restrictions, or risk-based restrictions such as • Technical limits per user, method, IP, business limits
location, first login on a device, recent attempts to unlock the • Monitoring
account, or similar. Verify that no more than 100 failed • Instrumentation
attempts per hour is possible on a single account. • Contract
• Rationale • Response
• Sharing
• Credential stuffing (and credential oracles)
• Limiting business losses and reputation damage • Unit Tests
• Attackers have excellent fuzzing and brute force tools • Try to call a sampling of sensitive methods such as enrolment,
• Human time is vastly different to fuzz time login, or transferring funds
• Many times, anti-automation provides sufficient protection • Test anti-automation limits such as exceeding enrolment
thresholds
• Relevant standards • Test responses
• OWASP Top 10 A2 • End to end integration tests
• Try to enroll a thousand times – it should fail
• NIST 800-63 x.x.x
• Try to login ten times fast with real creds – it should slow down
• PCI DSS 6.5.10 and then stop
• NIST 800-53 AC-2

2.2.2 Use push authenticators or better
• Verify that the use of weak authenticators (such as • Recommended solutions
SMS and email) is limited to secondary verification • Use TOTP or FIDO for authenticators
and transaction approval and not as a replacement • Enrol in push notifications for multifactor validation
for more secure authentication methods. Verify • If the user can’t enroll in push notifications, use email
that stronger methods are offered before weak or SMS or both
methods, users are aware of the risks, or that • Don’t send sensitive information over email and SMS
proper measures are in place to limit the risks of
account compromise. • Unit Tests
• Rationale • Test functional MFA or federated login
• SMS / SIM swap attacks • Test functional push, SMS, and email
• SMS is over SS7, which has precisely zero security • End to end integration tests
• Email is (typically) clear text transmission and storage • Enrol and test functional MFA or federated login
• Relevant standards • Enrol and test functional push, SMS, and email
• OWASP Top 10 A2
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.2.3 Notify users after account changes
• Verify that secure notifications are sent to users • Recommended solutions
after updates to authentication details, such as • Send push (and email or SMS at worst) notifications
credential resets, email or address changes, after account changes
logging in from unknown or risky locations. The • Password change
use of push notifications - rather than SMS or • Email change (to old and new)
email - is preferred, but in the absence of push • Phone change (to old and new)
notifications, SMS or email is acceptable as long as • Address change
no sensitive information is disclosed in the • High value business changes (i.e. disbursement accts)
notification.
• Unit Tests
• Rationale • Test functional push notifications
• Users are the best “free” IDS • Test functional email notifications
• Users can respond if they only knew • Test functional SMS notifications
• OWASP Top 10 A2 • Test functional push notifications
• OWASP Proactive Controls C6 • Test functional email notifications
• NIST 800-63 x.x.x • Test functional SMS notifications
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.3.1 Generate random initial passwords
• Verify system generated initial passwords or • Recommended solutions
activation codes SHOULD be securely randomly • Generate a random password for every new user,
generated, SHOULD be at least 6 characters long, including the initial administrator account
and MAY contain letters and numbers, and expire • Should comply with your password length policy
after a short period of time. These initial secrets • Force change password upon first login
must not be permitted to become the long-term
password. • Unit Tests
• Rationale • Generate 10,000 initial passwords
• Test for sufficient entropy (randomness)
• Static initial passwords like “admin” or “123456” are
rife • End to end integration tests
• We have payloads containing thousands of these • Enrol in an account n times
• Relevant standards • Compare resulting tokens to ensure that they are
different
• OWASP Top 10 A2
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.3.2 Allow users to use secure tokens they
already own
• Verify that enrollment and use of • Recommended solutions
subscriber-provided authentication • Use TOTP for most systems
devices are supported, such as a U2F or • Support FIDO Alliance keys for most and
FIDO tokens. higher value systems
• Rationale • Consider if federated authentication against
a public IDP is for you (Ping, Okta, social
• Users shouldn’t have to carry multiple networks, etc)
tokens
• Most hardware tokens are far stronger than • Unit Tests
TOTP • Enrol token
• MFA authenticator lifecycle is terrible • Change token
• Relevant standards • Login using {fake, expired, real} token
• OWASP Proactive Controls C6 • Enrol token
• NIST 800-63 x.x.x • Change token
• PCI DSS 6.5.10 • Login using {fake, expired, real} token
• NIST 800-53 AC-2

2.4.1 Securely hash passwords
• 2.4.1 Verify that passwords are stored in a form • Recommended solutions
that is resistant to offline attacks. Passwords SHALL • Advice changes rapidly: Use OWASP Password Cheat
be salted and hashed using an approved one-way Sheet
key derivation or password hashing function. Key • Select a random salt value
derivation and password hashing functions take a
password, a salt, and a cost factor as inputs when • Unit Tests
generating a password hash. • Test when creating a password that two close
passwords have very different hashes.
• Rationale
• We can crack literally trillions of passwords per second • End to end integration tests
• Most common lengths are instantaneous to not very • Not applicable
long on certain dedicated systems
• OWASP Top 10 A2
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.8.3 Use latest strong algorithms
• Verify that approved cryptographic • Recommended solutions
algorithms are used in the • Use standard algorithms with their
generation, seeding, and recommended settings
verification. • Unit Tests
• Rationale • Check that encrypted input is not
• Old, weak algorithms are broken plain text
• OWASP Top 10 A2 • Not applicable
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.5.1 Don’t send passwords in the clear
• Verify that a system generated initial activation or recovery • Recommended solutions
secret is not sent in clear text to the user. • Use time limited tokens
• Rationale • Tie them to that specific user
• Search almost everyone’s email account for passwords, and • Link them to a person where possible
you’ll get one or more
• Unit Tests
• Makes recovery emails very valuable
• Create a valid token
• Relevant standards • Test registration and recovery using
• OWASP Top 10 A2 • An expired token
• OWASP Proactive Controls C6 • A fake token
• NIST 800-63 x.x.x • A real token, but for a different user
• PCI DSS 6.5.10 • Try to recover or register for a different user with a valid token
• NIST 800-53 AC-2 • End to end integration tests
• Register or recover an account and fail if a clear text secret is
sent to the user
• Test registration and recovery pathways using expired, fake, real
tokens but for a different user
• Start the process of registration or recovery, gather a valid
token. At the “enter token” and then “set credential” steps, try
to use any other authenticated functionality

2.5.2 Kill knowledge-based authentication
• Verify password hints or • Recommended solutions
knowledge-based authentication • Kill it with fire
(so-called "secret questions") are • Unit Tests
not present.
• fail(“Kill it with fire”)
• Rationale
• Too easy to use OSINT to find answers
• They rarely add value • fail(“Kill it with fire”)
• Tell the lawyers you have a major
• Relevant standards privacy breach to really make sure it’s
• OWASP Top 10 A2 dead
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.5.4 No shared or default accounts
• Verify shared or default accounts are • Recommended solutions
not present (e.g. "root", "admin", or • Make the first account during installation
"sa"). dynamic, not fixed
• Password lists contain hundreds of • Try to login using a range of well known
thousands of these lists default accounts
• Folks never login to clear out all of these • If you had default accounts in the past,
• Security through obscurity never works try to use them in your tests
• OWASP Top 10 A2 • Try to login using a range of well known
default accounts
• If you had default accounts in the past,
• NIST 800-63 x.x.x try to use them in your tests
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.5.6 Secure credential recovery
• Verify forgotten password, and other recovery • Recommended solutions
paths use a secure recovery mechanism, such as • Accept two consecutive TOTP tokens
TOTP or other soft token, mobile push, or another • Send a push notification
offline recovery mechanism. • Notify the user that {credential, address, email, phone}
• Rationale change has happened
• KBA is a clear and present danger • Considering limiting high value transactions for a few
hours to a few days depending on what it is
• SMS is subject to number porting / SIM swapping
• Email is often tied to these two • Unit Tests
• Try to recover B’s account with A’s pathway
• Relevant standards • Try to recover an account with wrong information
• OWASP Top 10 A2
• Try to recover all accounts without being discovered
• NIST 800-63 x.x.x • End to end integration tests
• PCI DSS 6.5.10 • Test all account recovery paths
• NIST 800-53 AC-2 • Try to recover B’s account with A’s pathway
• Try to recover an account with wrong information
• Try to recover all accounts without being discovered

2.5.7 Identity proofing should be the same
• Verify that if OTP or multi-factor • Recommended solutions
authentication factors are lost, that • Establish a single standard for identity
evidence of identity proofing is proofing
performed at the same level as during • Use it for all registration and recovery
enrollment. pathways
• Answering “secret” questions is not as • The unit tests for identity proofing in
difficult as possessing a token registration and recovery should be
• Ditto sending an SMS or email to a device similar or the same
• OWASP Top 10 A2 • The integration tests for identity proofing
in registration and recovery should be
• OWASP Proactive Controls C6 similar or the same
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.8.6 Authenticators should be revokable
• Verify physical single factor OTP generator can • Recommended solutions
be revoked in case of theft or other loss. • Ensure that the current user can change their
Ensure that revocation is immediately password
effective across logged in sessions, regardless • Ensure that the current user can change their
of location. MFA device
• Rationale • Ensure that if you support biometrics, it’s not
just single factor
• Certificates and passwords can be revoked and
changed if broken • Unit Tests
• Biometrics can’t be revoked, so tie them to • changePassword() for current user
something that can be revoked • disableAccount() for current user
• Relevant standards • As user
• OWASP Top 10 A2 • As admin
• NIST 800-63 x.x.x • changePassword() for current user
• PCI DSS 6.5.10 • disableAccount() for current user
• NIST 800-53 AC-2 • As user
• As admin

2.10.1 No unchanging passwords or API keys
• Verify that integration secrets do not rely on • Recommended solutions
unchanging passwords, such as API keys or • Use SAML, OAuth or JWT with refresh tokens
shared privileged accounts. • Protect these tokens in secure key storage
• Rationale • Never put tokens in the URL
• API keys are the same as usernames + passwords • Unit Tests
• They are often found in code (GitHub has • Review connection unit tests to things like your
blocked over 1 billion tokens from being database
exposed!)
• Ensure that setup() does not contain an
• Old API with API keys in the URL, makes logs high unchanging secret
value targets
• Not applicable
• OWASP Top 10 A2
• NIST 800-63 x.x.x
• PCI DSS 6.5.10
• NIST 800-53 AC-2

2.10.3 Protect password hashes
• Verify that passwords are stored with • Recommended solutions
sufficient protection to prevent offline • Use a strong algorithm and random salt
recovery attacks, including local • Use a soft or hard HSM
system access. • Outsource to a federated authentication
• We already have every single password • Try performing indirect object reference
• Don’t become the next password dump attacks
victim • Try to set another user’s password
• Relevant standards • Try to retrieve another user’s password
• OWASP Proactive Controls C6 • Try performing indirect object reference
• NIST 800-63 x.x.x attacks to set
• PCI DSS 6.5.10 • Try to access other users’ passwords
• NIST 800-53 AC-2 • Try to reset other users’ passwords

Authentication Labs
• Secure Code Warrior A2
“Sample call out

quote design for
highlighting a
particular point in
your bullets”

Session management
TM
GLOBAL APPSEC DC
What is Session Management?
Who are you again? Oh it's you!!
Session management is like your

own personal PA who keeps track
of who you are, where you are and
what you are doing at all times
when using the application.

Some past breaches
• 17 Media Breach (30
million accounts
breached for a
streaming app
• the Aerticket
breach (data for 1.5
million German airline
passengers breached

3.1.1 Protect session tokens
• Verify the application never reveals session • Recommended solutions
tokens in URL parameters or error messages. • Make use of secure cookies
• Rationale • Always ensure SSL is used for delivery
• There is a good chance it will be logged, or • HttpOnly/SameSite attributes must be used
cached during the journey • Unit Tests
• Session replay attacks • Ensure that session and sensitive set cookie
• Session stealing attacks functions include current relevant security
attributes
• Relevant standards • “HttpOnly”
• OWASP Top 10 A2 • “secure”
• OWASP Proactive Controls C6 • “samesite”
• NIST 800-63 7.1 • End to end integration tests
• PCI DSS 6.5.10
• Ensure that session and sensitive set cookie
• NIST 800-53 SC-23 headers include current relevant security
attributes
• “HttpOnly”
• “secure”
• “samesite”

3.2.1 Regenerate session tokens on login
• Verify the application generates a • Recommended solutions
new session token on user • Use JWT, Oauth or SAML, where a
authentication. new token is generated as a result of
authentication
• Rationale • Regenerate session cookies if using
• Prevents session fixation session cookies. This is not easy on
• Reduces CSRF attacks J2EE
• Relevant standards • Unit Tests
• OWASP Top 10 A2 • Process a successful login
• OWASP Proactive Controls C6 • Determine if a new token has been
generated – pass
• NIST 800-63 7.1
• NIST 800-53 SC-23 • Login.
• Determine if a new session token was
set (JWT, Oauth, SAML, or cookie)
3.2.2 Strong session token entropy
• Verify that session tokens possess • Recommended solutions
at least 64 bits of entropy. • Use the most up to date session
manager from the application
• Rationale framework or SSO, SAML, JWT or
• Session brute forcing Oauth
• OWASP Top 10 A2 • Generate 1000 session IDs
• OWASP Proactive Controls C6 • Test the entropy of these using a
• NIST 800-63 7.1 randomness check
• NIST 800-53 SC-23 • Generate 1000 session IDs
• Test the entropy of these using a
randomness check

3.2.3 Secure client-side session token
storage
• Verify the application only stores session • Recommended solutions
tokens in the browser using secure • Use short lived / temporal HTML 5 storage
methods such as appropriately secured • Clear these values on idleness / logout
cookies or HTML 5 session storage.
• Unit Tests
• Rationale • Not applicable
• Shared browsers
• Hostile code from CDNs and partners • End to end integration tests
• Idle timeout
• Relevant standards • Setup – Login
• OWASP Top 10 A2 • Record values of HTML 5 tokens
• OWASP Proactive Controls C6 • (force idle timer)
• NIST 800-63 7.1 • Test that HTML local / session storage is clear
• PCI DSS 6.5.10 • Logout
• NIST 800-53 SC-23 • Setup – Login
• Record values of HTML 5 tokens
• Logout
• Test that HTML local / session storage is clear

3.2.4 Use framework session tokens
• Verify that session token are • Recommended solutions
generated using approved • Use the framework’s session manager
cryptographic algorithms. • Only have one
• Solved problem - creating your own • Not applicable
session manager is 10,000-35,000
lines of code you don’t need to write • End to end integration tests
• Relevant standards • Not applicable
• OWASP Top 10 A2
• OWASP Proactive Controls C6 • Architecture review
• NIST 800-63 7.1 • Ensure the use of a framework or
• PCI DSS 6.5.10 library for session management is in
• NIST 800-53 SC-23 place
• Ensure that it is the latest version

3.3.1 Invalidate session tokens on idle and
logout
• Verify that logout and expiration • Recommended solutions
•
invalidate the session token, such that the •
Ensure that idle timeouts per NIST 800-63 and risk are in place
Ensure both idle timeouts and logout effectively clear the
back button or a downstream relying session on the server
party does not resume an authenticated • Unit Tests
session, including across relying parties. • Idle and logout timeouts
•
• Rationale •
Client side - test clearing session tokens
Server side – test clearing session tokens
• Shared, public computers • End to end integration tests
• Users now expect apps to time out and may • Idle timeouts
not logout • Login
•
• Back button is a thing •
Test that you can view or use high value functionality
Wait x minutes or force idle timeout timer
• Relevant standards •
•
Logout
Test that you can’t view or use high value functionality
• OWASP Top 10 A2 • Login

• OWASP Proactive Controls C6 •
•
Test that you can view or use high value functionality
Logout
• NIST 800-63 7.1 • Simulate a “back” button navigation
• PCI DSS 6.5.10 • Test that you can’t view or use high value functionality
• NIST 800-53 SC-23

3.3.2 Reauthenticate every X days
• Verify if authenticators permit users to • Recommended solutions
• Implement longer idle time outs
remain logged in, verify that re- • Consider implementing re-authentication for high value functions after a
authentication occurs periodically both •
suitable period
Enforce X day re-authentication (such as 30 days)
when actively used or after an idle
• Unit Tests
period. • Test longer idle timeouts
• Rationale •
•
Login
Mock idle timeout
• Low risk: 20 minute timeouts are unlikely to • Re-authenticate?
be truly necessary • Test re-authentication after X days
• Login
• Users might need to work longer than the • Mock day timeout
traditional timeouts • Re-authenticate?

• Test longer idle timeouts
•
• OWASP Proactive Controls C6 •
Mock idle timeout
Re-authenticate?
• NIST 800-63 7.1 • Test re-authentication after X days
•
• PCI DSS 6.5.10 •
Login
Mock day timeout
• NIST 800-53 SC-23 • Re-authenticate?

3.3.3 Terminate active sessions after a
credential change
• Verify that the application terminates all other • Recommended solutions
active sessions after a successful password change, • Notify all logged in sessions to invalidate
and that this is effective across the application, • Web Sockets?
federated login (if present), and any relying parties.
• Unit Tests
• Rationale • Change credential + Invalidation
• If someone is busy resetting a password to recover • Login on two sessions, A & B
access to an account, they will want the attacker’s
Oauth tokens and access revoked too • Session A: Change password
• Test: Session B: notified of being logged out?
• OWASP Top 10 A2
• Change credential + Invalidation
• NIST 800-63 7.1
• Login on two sessions
• PCI DSS 6.5.10 • Session A: Change password
• NIST 800-53 SC-23 • Test: Session B: logged out?
• If using federated authentication, check that this
works across all relying parties
• Tokens revoked?
• Users notified?

3.3.4 Users should be able to vet active
sessions
• Verify that users are able to view and log • Recommended solutions
out of any or all currently active sessions • Implement an view active session feature,
and devices. with logout / revoke button
• Rationale • Should contain enough information to allow
a user to work out if there is a problem
• Customer experience
• Users are the best form of IDS • Unit Tests
• Test active session API
• Relevant standards • Should include current session
• OWASP Top 10 A2 • Test terminate / logout session API
• NIST 800-63 7.1 • End to end integration tests
• PCI DSS 6.5.10 • Login twice (A, B)
• NIST 800-53 SC-23 • View active sessions
• Should include current session A and B
• Test terminate / logout session API
• As A, terminate B
• B logged out?

3.4.5 Use a precise “path” for session
cookies
• Verify that if the application is published • Recommended solutions
under a domain name with other • Implement a tight path setting for session
applications that set or use session cookies
cookies that might override or disclose • Be mindful of SSO platforms
the session cookies, set the path attribute
in cookie-based session tokens using the • Unit Tests
most precise path possible. • Test that session cookie header values
include a path string
• Rationale
• Prevents some forms of sub-domain • End to end integration tests
takeover • Test that session cookie header values
include a path string
• Relevant standards • Try to login from outside that path – should
• OWASP Top 10 A2 fail
• OWASP Proactive Controls C6 • Try to login from inside the path – should
• NIST 800-63 7.1 pass
• PCI DSS 6.5.10
• NIST 800-53 SC-23

3.5.2 Use dynamic session tokens
• Verify the application uses session tokens • Recommended solutions
rather than static API secrets and keys, • Use anything other than API keys
except with legacy implementations.
• Unit Tests
• API keys are the same as a username +
password. Usually appear in the URL or • End to end integration tests
logged • Review API documentation for any methods
• OAuth tokens are different for each user that supports API keys
• Session cookies are different for each user • Test an invalid API key – return 410 (“Gone”)
• Test a valid API key – return 410 (“Gone”)
• OWASP Top 10 A2
• NIST 800-63 7.1
• PCI DSS 6.5.10
• NIST 800-53 SC-23

3.5.3 Use the latest JWT and OAuth
implementations
• Verify that stateless session tokens use • Recommended solutions
digital signatures, encryption, and other • Use OWASP Dependency Check to ensure
countermeasures to protect against that the latest libraries are in use
tampering, enveloping, replay, null cipher, • Unit Tests
and key substitution attacks.
• Not applicable
• Rationale
• Older reference implementations had • End to end integration tests
serious design flaws • Not applicable (see V14.2.1)
• Newer versions reflect latest security fixes
• OWASP Top 10 A2
• NIST 800-63 7.1
• PCI DSS 6.5.10
• NIST 800-53 SC-23

3.7.1 Valid system generated session
• Verify the application ensures a valid login • Recommended solutions
session or requires re-authentication or • Use the frameworks’ session manager
secondary verification before allowing any • Use the latest implementations of SSO, JWT,
sensitive transactions or account Oauth, and SAML libraries
modifications.
• Unit Tests
• Rationale • Invalid session id – should fail
• Session fixation • Valid session id - pass
• Attackers set their own known session ID
• Strong session managers should only accept • End to end integration tests
their own session identifiers • Attempt to set a completely invalid session id
(“ridiculous”) - fail
• Relevant standards • Attempt to set an expired session id – fail
• OWASP Top 10 A2 • Attempt to create a new session id – fail
• OWASP Proactive Controls C6 • Session fixation - create a new session ID from
• NIST 800-63 7.1 User A, provide a link with this session ID to a
• PCI DSS 6.5.10 user B, force browse to the link, see if the forced
• NIST 800-53 SC-23 session ID from User A is used with User B - fail

Session management lab
• Secure Code Warrior

Access control
Acting as admin since 1998

What is Access Control?
You might be allowed in the club,

but that doesn't mean you can be
the DJ.
Access control ensures you are

allowed to do only what the site
owner wants you to do.

Notable Hacks
ClixSense breach in which
hackers obtained control
over hosting servers and
were able to gain access
to sensitive back-end
systems
Three breach in which
physical phones were
stolen by manipulating an
operator’s website.
1.4.1 Trusted enforcement points
• Verify that trusted enforcement points • Recommended solutions
such as at access control gateways, • Implement server side (trusted)
servers, and serverless functions enforce enforcement points for access controls
access controls. Never enforce access • Optionally, consider implementing client
controls on the client. side UX if you want, but 100% bypassable
• Client-side controls can always be bypassed • Test server side / API access controls
• Detection can be disabled if on client • User authenticated
• Attackers can write their own end points • User is not signing up / resetting
• User in role
• OWASP Proactive Controls C7 • Clear login
• Test that all but login, enrollment, public, and
• PCI DSS 6.5.8 credential reset server-side calls do not work
• NIST 800-53 AC-3, AC-6, AC-24 • Login as each role
• Test each server-side call is permitted or
denied per the access control matrix

1.4.4 Single access control mechanism
• 1.4.4 Verify the application uses a single and • Recommended solutions
well-vetted access control mechanism for • Use your framework’s access control
accessing protected data and resources. All • Only permit one access control mechanism
requests must pass through this single throughout the code
mechanism to avoid copy and paste or
insecure alternative paths. • Unit Tests
• Not applicable
• Rationale
• Weakest link in the chain vulnerabilities • End to end integration tests
• Increased costs - additional code to vet and • Not applicable
secure • Architecture Review
• Multiple security models may lead to confusion, • Review access control mechanisms
missing or ineffective access control checks
• If more than one – fail
• OWASP Top 10 A5
• PCI DSS 6.5.8
• NIST 800-53 AC-3, AC-6, AC-24

4.1.1 Trusted access control enforcement
• Verify that the application enforces access control • Recommended solutions
rules on a trusted service layer, especially if client- • Identity providers should enforce access controls on a
side access control is present and could be trusted layer (policy enforcement point, or PEP)
bypassed. • Ensure Policy Authority Points (access control policy /
rules / metadata) are protected and located on a
• Rationale trusted layer
• Client-side access control is trivially bypassed
• Access control metadata such as policy, matrices, roles
• Unit Tests
and so on must not be on the client, or if they are, • Test access control matrices as per normal
considered for CX only
• Relevant standards • Client-side – test access control bypass
• OWASP Top 10 A5 • Unauthenticated - fail
• OWASP Proactive Controls C7 • Authenticated but not in role - fail
• PCI DSS 6.5.8 • Authenticated and in role - pass
• NIST 800-53 AC-3, AC-6, AC-24 • Client-side – attempt to update roles for a user
• Unauthenticated – should fail
• Authenticated as the user – should fail
• Authenticated as the admin – should pass
• Client side – attempt to update access control
policies with and without authentication

4.1.3 Principle of Least Privilege
• Verify that the principle of least privilege • Recommended solutions
exists - users should only be able to access • Implement “deny by default” so that users start
functions, data files, URLs, controllers, out with no access
services, and other resources, for which they • Implement role based or capability-based access
possess specific authorization. This implies controls by adding to “no access”
protection against spoofing and elevation of • Apply roles or capabilities to users as they need
privilege.
• Unit Tests
• Rationale • Needs a set of unit tests for each feature
• Users should not have access if you forget to • Test unauthenticated access to a normal and
apply permissions or a role privileged function – should fail
• Allows vertical privilege escalation • Test authenticated access from
• Attackers may know about your privileged • User A to admin functionality – should fail
functionality and try to abuse it before you do • User A to User B functionality – should fail
• Relevant standards • Admin B to admin functionality – should pass
• OWASP Proactive Controls C7 • For every feature, repeat the above tests, but
• PCI DSS 6.5.8 using end to end testing tooling
• NIST 800-53 AC-3, AC-6, AC-24

4.1.4 Principal of Deny by Default
• Verify that the principle of deny by default • Recommended solutions
exists whereby new users/roles start with • Privilege definitions should start with no access
minimal or no permissions and users/roles do
not receive access to new features until • Unit Tests
access is explicitly assigned. • Per previous slide
• Rationale • End to end integration tests
• Users should not have implicit access to any • Per previous slide
resource, only those they are explicitly allowed
• Used in many data breaches
• Exposed buckets and files
• Exposed records
• IDORs
• OWASP Top 10 A5
• PCI DSS 6.5.8
• NIST 800-53 AC-3, AC-6, AC-24

4.1.5 Access controls fail closed
• Verify that access controls fail securely including • Recommended solutions
when an exception occurs. • Use structured exception handling or a global error
handler
• Rationale • Implement user actionable error messages with
• Attackers are experts in creating errors using hostile minimal information
inputs
• Errors should not result in access • Unit Tests
• For each access control enforcement method, test:
• Relevant standards • Provide random garbage
• OWASP Top 10 A5 • Provide nearly correct data
• OWASP Proactive Controls C7 • Mock an exception or an error
• PCI DSS 6.5.8
• NIST 800-53 AC-3, AC-6, AC-24
• For each privileged action that takes data, test:
• Random garbage of varying types and length
• Missing parameters
• Fuzz lists from SecLists including universal locators
• Nearly correct inputs
• Correct inputs
• None of these should end up granting access to
privileged functionality or data

4.2.1 Protect against direct object attacks
• Verify that sensitive data and APIs are • Recommended solutions
• Includes anything that is real – session objects, objects, data, primary or
protected against direct object attacks secondary keys, files, UUIDs or GUIDs, locks and semaphors, etc
targeting creation, reading, updating and •
•
Random or static indirect object references
Protect all direct object references:
deletion of records, such as creating or • Controller – enforce access control matrix
updating someone else's record, viewing • Model – enforce data access role matrix
everyone's records, or deleting all • Domain – create/enforce data queries or object access that limits to
minimal sets
records. • Multi-tenant – use a per client crypto key and encrypt data so that
inadvertent direct object access does not decrypt
• Rationale •
•
Access control checks (PUT, POST, DELETE, etc)
Implement DOR auditing / monitoring / escalation
• Primary data breach mechanism • Unit Tests
• Billions of records stolen using one of the • Create several records for two users
simplest attacks • Test unauthenticated access to a DOR – fail
• As user A, try to create, read, update, delete User B’s records
• Relevant standards • As user B, try to access non-existent, valid for the user, invalid for the user
•
• OWASP Top 10 A5 Try to access all known objects, should trigger audits and warnings
• OWASP Proactive Controls C7 • Same as unit tests
• PCI DSS 6.5.8
• NIST 800-53 AC-3, AC-6, AC-24

4.2.2 Include CSRF protections
• Verify that the application or • Recommended solutions
framework enforces a strong anti- • Use your framework’s CSRF
CSRF mechanism to protect implementation
authenticated functionality, and • If your framework or language doesn’t
effective anti-automation or anti-CSRF have it, use the OWASP CSRF cheat sheet
protects unauthenticated to build it in
functionality. • Unit Tests
• Rationale • Missing CSRF token - fail
• CSRF is a thing • Invalid CSRF token – fail
• Clickjacking and stealing clicks • Valid CSRF token – pass
• OWASP Proactive Controls C7 • Missing CSRF token - fail
• Invalid CSRF token – fail
• PCI DSS 6.5.8 • Valid CSRF token – pass
• NIST 800-53 AC-3, AC-6, AC-24

4.3.1 Administrative interfaces require MFA
• Verify administrative interfaces use • Recommended solutions
appropriate multi-factor authentication to • Mandate MFA for privileged roles
prevent unauthorized use. • Enforce administrative / privileged access control
• Rationale checks
• Administrators are just another role – it’s about • Unit Tests
identity, not location • Same as any other privileged role
• Attackers actively seek out vertical horizontal • Test for unauthenticated access – should fail
privilege escalation • Test for authenticated access without MFA – should
• The old days of admin panels behind the fail
gossamer thin curtain have always been done • Test for authenticated access with MFA – should pass
• OWASP Top 10 A5 • Test for unauthenticated access
• OWASP Proactive Controls C7 • Test high value function access or use – should fail
• PCI DSS 6.5.8 • Login as an administrator account without MFA
• NIST 800-53 AC-3, AC-6, AC-24 • Test high value function access or use – should fail
• Login as an administrator account with MFA
• Test high value function access or use – should pass

4.3.2 Don’t turn on directory browsing
• Verify that directory browsing is • Recommended solutions
disabled unless deliberately desired. • Don’t weaken the default configuration
Additionally, applications should not • If you do need directory browsing, ensure
allow discovery or disclosure of file or there’s no sensitive data contained within
directory metadata, such as • Unit Tests
Thumbs.db, .DS_Store, .git or .svn
folders. • Not applicable
• Google dorks • Try to access known directories such as
/admin/ or /logs/
• Data breaches containing sensitive data • If granted access, check for file listings
• OWASP Top 10 A5
• PCI DSS 6.5.8
• NIST 800-53 AC-3, AC-6, AC-24

4.3.3 High value step up authorization
• Verify the application has additional • Recommended solutions
authorization (such as step up or adaptive • Review all high value transactions
authentication) for lower value systems, and / • Per the risk of the application, consider
or segregation of duties for high value implementing step up authentication
applications to enforce anti-fraud controls as • For very high value, consider implementing
per the risk of application and past fraud. segregation of duties (initiator, approver,
receiver)
• Rationale
• Prevents CSRF • Unit Tests
• Prevents accidental muling • Attempt to use high value transaction with null
• Segregation of duties (initiator, approver, or invalid credential – should fail
receiver) • Use high value transaction with valid credential –
should pass
• OWASP Proactive Controls C7 • Attempt to use high value transaction with null
or invalid credential – should fail
• PCI DSS 6.5.8 • Use high value transaction with valid credential –
• NIST 800-53 AC-3, AC-6, AC-24 should pass

Authorization Labs
SECURE CODE WARRIOR
Input
validation and output encoding
Inject all the things
TM
GLOBAL APPSEC DC
What is Input Validation & Output
Encoding?
So you are inside, you fancy a
beer and the barman hands you
water from the toilet. Do you
drink it?
Validating both what's coming

in and going out has been an
eternal struggle since the dawn
of time. Get this wrong and all
hell breaks loose.
Notable Hacks
Take your pick, there are
so many!
• The Philippines’ Commission on
Elections breach, in which
77,736,795 records, representing
the entire adult population of the
Philippines (!) were stored in
plaintext and easily obtained by a
hacker via SQL injection.

1.5.1 Input and output architecture
• Verify that input and output • Recommended solutions
requirements clearly define how to • Input validation CX at entry
handle and process data based on • Input validation enforcement close to
type, content, and applicable laws, entry
regulations, and other policy • Output encoding just prior to interpreter
compliance. • Be strict with what you accept, and send
• Rationale • Architecture review
• Differing mechanisms in different areas • Sample a set of inputs
results in exploiting different interpreters • Validate that validation enforcement is
• Orange Tsai’s SSRF research near entry
• Relevant standards • Validate that output encoding occurs just
prior to the relevant interpreter, with the
• OWASP Top 10 A1, A4, A7 correct context
• OWASP Proactive Controls C4 and C5
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

1.5.2 Serialization architecture
• Verify that serialization is not used when • Recommended solutions
communicating with untrusted clients. If • Don’t send serialized objects to clients
this is not possible, ensure that adequate • If you have to send serialized objects, use a
integrity controls (and possibly encryption safer format, like JSON and a well known
if sensitive data is sent) are enforced to JSON library
prevent deserialization attacks including • Architecture Review
object injection.
• Review trust boundaries and determine if
• Rationale any serialized objects flow across them
• Remote code execution • What controls are in place to prevent
• Big payouts for bug bounties deserialization attacks
• There are easier ways • Integrity controls (per JWT)
• Confidentiality controls
• Relevant standards • Replay controls
• OWASP Top 10 A1, A4, A7
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

1.5.3 Input validation architecture
• Verify that input validation is • Recommended solutions
enforced on a trusted service layer. • Implement a single conceptual view
• Rationale of input validation using known
trusted validation libraries in trusted
• Client side validation is trivially components
bypassed • Implement client-side validation for
• All injections etc rely on this failure CX only
• Relevant standards • Architecture review
• OWASP Top 10 A1, A4, A7 • Review trust boundaries where
• OWASP Proactive Controls C4 and C5 untrusted data is received, processed
• PCI DSS 6.5.1 and 6.5.7 or stored by trusted components
• NIST 800-53 SI-9 SI-10 SI-15 • Determine the input validation
mechanisms in the trusted
components to handle hostile data
inputs

1.5.4 Output encoding architecture
• Verify that output encoding occurs • Recommended solutions
close to or by the interpreter for • Output encoding should occur as
which it is intended. close to the interpreter as possible
• Rationale • Data must be output encoded for that
interpreter (only)
• All injections are caused by the lack of • Use safer mechanisms that escaping
output encoding or the use of safer where possible (parameterized
parameterized queries or auto- queries, ORMs, auto-escaping
encoded templaters templaters, etc)
• Relevant standards • Architecture Review
• OWASP Top 10 A1, A4, A7 • Determine output encoding strategy
• OWASP Proactive Controls C4 and C5 • Sample database and web rendering
• PCI DSS 6.5.1 and 6.5.7 sinks for output encoding
• NIST 800-53 SI-9 SI-10 SI-15 • Missing, ineffective, effective?

5.1.1 Parameter Pollution Prevention
• Verify that the application has • Recommended solutions
defenses against HTTP parameter • Be specific about where parameters
pollution attacks, particularly if the should come from (GPCES)
application framework makes no • Caution: PHP with $_REQUEST
distinction about the source of • Unit Tests
request parameters (GET, POST,
cookies, headers, or environment • Not applicable
variables). • End to end integration tests
• Rationale • Should fail:
• Submit a URL parameter and a body
• Bypass input validation parameter with the same name
• Relevant standards • Submit a body value as a cookie
• OWASP Top 10 A1, A4, A7 • Submit a body value as a URL
• Submit a cookie value in the URL
• OWASP Proactive Controls C4 and C5 • Submit a cookie value in the body
• PCI DSS 6.5.1 and 6.5.7 • Submit a URL value in body
• NIST 800-53 SI-9 SI-10 SI-15 • Submit a URL value in cookies

5.1.2 Mitigate mass parameter assignment
• Verify that frameworks protect against • Recommended solutions
mass parameter assignment attacks, • Use whitelisting bindable, non-sensitive
or that the application has fields.
countermeasures to protect against • Blacklist non-bindable, sensitive fields
unsafe parameter assignment, such as • Unit Tests
marking fields private or similar.
• Use fuzzing of the parameter to detect
• Rationale changes
• Bypass field access controls • Fuzz the parameter value for different
• Bypass input validation data types (integers, strings, etc.)
• Bypass WAFs • End to end integration tests
• Relevant standards • Include private fields in requests which
use auto-binding
• Fail if this takes effect in the application
• OWASP Proactive Controls C4 and C5 (such as promotion to admin, changed
• PCI DSS 6.5.1 and 6.5.7 balance, or similar)
• NIST 800-53 SI-9 SI-10 SI-15

5.1.3 Positive validation preferred
• Verify that all input (HTML form fields, • Recommended solutions
REST requests, URL parameters, HTTP • Use positive validation where possible
headers, cookies, batch files, RSS (i.e. not text fields)
feeds, etc) is validated using positive • In text fields, use length restrictions,
validation (whitelisting). positive character filtering, and negative
validation
• Rationale
• Positive validation is specific and fast • Unit Tests
• Negative validation assumes you know • Submit a wide range of input data,
more about the data than an attacker particularly from SecLists to text fields
• Ensure that validations fail securely
• OWASP Top 10 A1, A4, A7 • End to end integration tests
• OWASP Proactive Controls C4 and C5 • Same as unit tests
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

5.1.4 Strongly type data (no, seriously)
• Verify that structured data is strongly typed • Recommended solutions
and validated against a defined schema • Consider using typed languages (TypeScript
including allowed characters, length and instead of JavaScript, C# or Java, Go, etc)
pattern (e.g. credit card numbers or • Unit Tests
telephone, or validating that two related
fields are reasonable, such as checking that • Send in a range of SecLists string payloads to
suburb and zip/postcode match). functions that should be accepting non-strings
• Most injections don’t work if you convert them • Same as Unit Tests
to booleans, integers, or dates
• Reduce defects before you go live
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

5.1.5 Static redirection and forwards
• Verify that URL redirects and forwards • Recommended solutions
only allow whitelisted destinations, or • Don’t send the URL to the client, ever.
show a warning when redirecting to • Internally, have a static or protected URL
potentially untrusted content. destination
• Open Redirection was a part of the • Review code that might send a redirect or
OWASP Top 10 for nearly 15 years a 302 message
• Bypasses many security checks • Inject hostile URLs into any parameters
• Makes attacks more believable • Determine if the 302 contains the hostile
parameter
• OWASP Top 10 • End to end integration tests
• OWASP Proactive Controls • For parameters that take URLs or routes
as a destination, include hostile URL
• NIST 800-63 payloads
• PCI DSS 6.5.x • Determine if the response contains the
• NIST 800-53 hostile URL

5.2.1 Sanitize HTML and Markdown input
• Verify that all untrusted HTML input from • Recommended solutions
WYSIWYG editors or similar is properly • Use one of the more popular HTML
sanitized with an HTML sanitizer library or sanitization or markdown libraries
framework feature. • Use auto-templaters to protect against XSS
• It’s not possible to completely determine • Inject hostile HTML (XSS locators)
the complete “safe” mark up of HTML or • Inject hostile markdown (XSS locators)
Markdown due to version and dialect
changes • End to end integration tests
• HTML 4.0 apps are often at risk when using • Inject hostile HTML (XSS locators)
HTML 5.0 browsers • Inject hostile markdown (XSS locators)
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

5.2.2 Enforce unstructured data restrictions
• Verify that unstructured data is • Recommended solutions
sanitized to enforce safety • Enforce typing if possible
measures such as allowed • Restrict length
characters and length. • Restrict composition
• Rationale • Name variables and methods in such
• Unstructured data is particularly a way as to indicate dangerous source
difficult to validate • Unit Tests
• Still a source of injections and XSS • Test a wide variety of payloads to
• Relevant standards unstructured parameters
• OWASP Proactive Controls C4 and C5 • Test a wide variety of payloads to
• PCI DSS 6.5.1 and 6.5.7 unstructured parameters
• NIST 800-53 SI-9 SI-10 SI-15

5.2.4 eval() is evil()
• 5.2.4 Verify that the application avoids • Recommended solutions
the use of eval() or other dynamic • Eliminate eval()
code execution features. Where there • Disable features that allow eval()
is no alternative, any user input being • Don’t allow user input in eval()
included must be sanitized or • Sandbox eval() execution with containers
sandboxed before being executed. or similar (now you have two problems!)
• Remote Code Execution • Test with eval and OS command payloads
• Object and state manipulation
• Compromise of systems
• Test with eval and OS command payloads
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

5.2.5 Protect against template injection
• Verify that the application protects • Recommended solutions
against template injection attacks by • Use auto-escaping template frameworks
ensuring that any user input being • Unit Tests
included is sanitized or sandboxed.
• Test with XSS and template injection
• Rationale payloads
• XSS injection • Ensure the resulting HTML or DOM writes
• Expression language injection do not contain XSS
• Template language injection • End to end integration tests
• Relevant standards • Test with XSS and template injection
payloads
• Ensure the resulting DOM does not
• OWASP Proactive Controls C4 and C5 contain active XSS
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

5.2.6 Protect against Server Side Request
Forgery (SSRF)
• Verify that the application protects against SSRF • Recommended solutions
attacks, by validating or sanitizing untrusted data • Avoid using user supplied filenames and URLs
or HTTP file metadata, such as filenames and URL • Decompose and positively validate all portions of
input fields, use whitelisting of protocols, domains, supplied filenames and URLs
paths and ports. • Force containers and servers to communicate through a
• Rationale whitelist only proxy
• Containers – block and monitor all (new) outbound
• Most commonly attacked issue in cloud environments communication
• SSRF is prevalent but underreported
• Not well known amongst devs as not in Top 10 • Unit Tests
• Attackers know how to exploit • Test with SSRF payloads against known canary
• Fail if resulting (mock) connection might open a
• Relevant standards connection to the canary
• Test with SSRF payloads with known canary filename or
• PCI DSS 6.5.1 and 6.5.7 URL
• NIST 800-53 SI-9 SI-10 SI-15 • Fail if the canary system receives any connections
• If blocking all outbound connections on a container,
check for attempted connections in logs

5.3.1 Contextually correct output encoding
Verify that output encoding is relevant for the • Recommended solutions
interpreter and context required. For example, use • Use an auto-escaping template that automatically
encoders specifically for HTML values, HTML performs contextual escaping
attributes, JavaScript, URL Parameters, HTTP headers, • Or determine the output context of the interpreter in
SMTP, and others as the context requires, especially use, and find a library to perform that output encoding
from untrusted inputs including Unicode or • Don’t double encode
apostrophes. • Don’t store encoded
• Context is critical – SMTP is not HTML attributes • Compose a template with XSS or template encoded XSS
• A-Za-z0-9 is unlikely to be acceptable in most parts of • Failed if active XSS is present in the HTML to be
the world rendered
• Unicode has many spaces, many “I”s and so on
• Relevant standards • Use XSS or template encoded XSS payloads for
• OWASP Top 10 A1, A4, A7 parameters likely to be included in templates or on
• OWASP Proactive Controls C4 and C5 screen
• PCI DSS 6.5.1 and 6.5.7 • Failed if active XSS is present in the resulting DOM
• NIST 800-53 SI-9 SI-10 SI-15

5.3.10 Prevent XPath and XML injection
against XPath injection or XML • Use modern XML libraries
injection attacks. • Disable XML external entities
• Rationale • Use XML escaping mechanisms
• Disclose sensitive data from other users • Don’t hand construct Xpath or XML
documents
• XML node injection
• XXE and other XML related attacks • Unit Tests
• External entities = SSRF • Fail if the result is not expected
• Test a safe Xpath / XML / XSL payload
• Relevant standards • Test XML fuzz and XXE payloads from
• OWASP Top 10 A1, A4, A7 SecLists
• OWASP Proactive Controls C4 and C5 • End to end integration tests
• PCI DSS 6.5.1 and 6.5.7 • Fail if the result is not expected
• NIST 800-53 SI-9 SI-10 SI-15 • Test a safe Xpath payload
• Test XML fuzz and XXE payloads from
SecLists

5.3.3 Use auto-escaping templaters
• Verify that context-aware, preferably automated - • Recommended solutions
or at worst, manual - output escaping protects • Use auto-escaping template solutions
against reflected, stored, and DOM based XSS. • Angular – use context methods provided
• Rationale • React – only one single method
• Handlebars, etc
• Figuring out the context is hard
• Be wary of concatenating user supplied inputs to create
• Code with manual escaping is difficult to read templates
• Even one missed parameter will result in XSS
• Unit Tests
• Relevant standards • For each source parameter used in output, test
• OWASP Top 10 A1, A4, A7 • expected values
• OWASP Proactive Controls C4 and C5 • SecLists XSS fuzzes
• PCI DSS 6.5.1 and 6.5.7 • SecLists HTML 5 fuzzes
• NIST 800-53 SI-9 SI-10 SI-15 • Fail if XSS is part of a resulting response
• For each source parameter used in output, inject
• expected values
• SecLists XSS fuzzes
• SecLists HTML 5 fuzzes
• Fail if XSS results from this testing

5.3.4 Use safe data access frameworks
• Verify that data selection or database • Recommended solutions
queries (e.g. SQL, HQL, ORM, NoSQL) use • Use parameterized queries, ORMs, entity
parameterized queries, ORMs, entity frameworks
frameworks, or are otherwise protected • Use SQL encoding if parameterized queries
from database injection attacks. are not available
• Rationale • You can’t escape table names, column
names, clauses, and SQL metadata
• SQL injections used to be one of the most
common methods of data breaches • Unit Tests
• Advanced exploitation tools make SQL • Test models with SQL injection locators and
injection accessible to even weak attackers fuzz lists
• Impact is off the charts • End to end integration tests
• Relevant standards • Where input data ends up in a query, inject
• OWASP Top 10 A1, A4, A7 SQL injection locators and fuzz lists
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

5.3.6 Prevent JavaScript and JSON injection
• Verify that the application projects • Recommended solutions
against JavaScript or JSON injection • Use safer JSON libraries, like GSON
attacks, including for eval attacks, remote • Input validation
JavaScript includes, CSP bypasses, DOM • Don’t use eval()
XSS, and JavaScript expression evaluation. • Auto-escaping expressions and output
• Rationale • Send a content security policy header
• Most modern applications are now written • Unit Tests
using JavaScript
• JavaScript and JSON have many ways of • Similar to XSS tests; include JSON fuzz lists
evaluating user supplied code • End to end integration tests
• Not commonly tested today • Similar to XSS tests; include JSON fuzz lists
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

5.3.7 Prevent LDAP injection
• Verify that the application protects against LDAP • Recommended solutions
Injection vulnerabilities, or that specific security • Sanitize and validate user supplied input prior to
controls to prevent LDAP Injection have been constructing LDAP queries
implemented. • Check that the number of results matches expected
values (i.e. a search for a user returns one result)
• Rationale • Use LinqtoAD if on .NET, which automatically escapes
• Bypass authentication LDAP
• Not commonly tested (properly)
• Rare attack
• Unit Tests
• Test LDAP functionality with:
• LDAP libraries rarely have LDAP encoders
• Good usernames + passwords - pass
• Relevant standards • Good usernames with no / bad passwords - fail
• OWASP Top 10 A1, A4, A7 • Inject LDAP fuzz lists into username and password fields
– should not login
• PCI DSS 6.5.1 and 6.5.7 • End to end integration tests
• NIST 800-53 SI-9 SI-10 SI-15 • Test LDAP functionality with:
• Good usernames + passwords - pass
• Good usernames with no / bad passwords - fail
• Inject LDAP fuzz lists into username and password fields
– should not login

5.3.8 Prevent OS Command Injection
• Verify that the application protects against OS • Recommended solutions
command injection and that operating system • Don’t use user supplied data with system()
calls use parameterized OS queries or use • Use parameterized OS command methods if user
contextual command line output encoding. supplied data is required
• Rationale • With PHP, there is a multitude of ways to
perform system() style code execution
• Remote code execution
• Complete compromise of underlying host • Unit Tests
• Lateral movement • Inject fuzz lists into methods that call out to the
system
• Relevant standards • UnixAttacksFuzzDB.txt
• OWASP Top 10 A1, A4, A7 • WindowsAttacksFuzzDB.txt
• OWASP Proactive Controls C4 and C5 • End to end integration tests
• PCI DSS 6.5.1 and 6.5.7 • Set up a canary and adjust the fuzz list to address
• NIST 800-53 SI-9 SI-10 SI-15 the canary (or use Burp Collaborator)
• Inject OS command fuzz lists into parameters
that are the original source for those parameters

5.3.9 Prevent file inclusion attacks
against Local File Inclusion (LFI) or • Don’t use user supplied file metadata
Remote File Inclusion (RFI) attacks. or names directly with files
• Rationale • Block or whitelist proxy new
outbound connections from
• Path traversal containers and servers
• Server side includes • Unit Tests
• LFI/RFI/SSRF
• For components that deal with the
• Data exfiltration file system, fuzz input parameters
• Relevant standards with LFI / RFI / path traversal lists
• OWASP Proactive Controls C4 and C5 • For UI components that allow file
• PCI DSS 6.5.1 and 6.5.7 uploads, fuzz LFI / RFI / path traversal
• NIST 800-53 SI-9 SI-10 SI-15 • Try SSRF fuzzing with canaries

5.4.1 Prevent buffer overflows
• Verify that the application uses memory-safe • Recommended solutions
string, safer memory copy and pointer arithmetic • Review use after free / JOP / ROP / stack / heap
to detect or prevent stack, buffer, or heap overflow techniques and JS sandbox escapes
overflows. • Review “Writing Secure Code” to avoid known insecure
memory allocation, heap, and so on
• Rationale • Use a safer language like Go, Rust, or Swift
• Buffer overflows allow arbitrary code execution on your • Compile C / C++ / Objective C with stack cookies /
servers or the victim’s system guard / canary switches and pointer authentication
• One of the oldest forms of malicious code on the (PAC) on iOS A12 platforms
Internet (Morris Worm - 1988)
• Scan code with static code analysis tools to find
• Alignment with PCI DSS potential buffer overflows
• OWASP Top 10 A1, A4, A7 • Test with null pointers
• OWASP Proactive Controls C4 and C5 • Test with n-1, n, and n+1 words
• PCI DSS 6.5.2 • Fuzz with over large data inputs
• NIST 800-53 SI-9 SI-10 SI-15 • Integer overflows (wrap arounds) even work in Java
• As per unit tests; emulate null pointers in many
instances by not including the parameter

5.4.2 Use format strings carefully
• Verify that format strings do not • Recommended solutions
take potentially hostile input and • Review any use of printf, sprintf,
are constant. snprintf etc
• As per buffer overflows
• Rationale
• Pathway to simple buffer overflows • Unit Tests
• As per buffer overflows
• OWASP Proactive Controls C4 and C5 • As per buffer overflows
• PCI DSS 6.5.2
• NIST 800-53 SI-9 SI-10 SI-15

5.4.3 Validate numbers for sign and range
• Verify that sign, range, and input • Recommended solutions
validation techniques are used to • Validate for sign (especially unsigned)
prevent integer overflows. • -0 is a thing
• Rationale
• Natural numbers for quantities
• Quantities in business logic
• Java integer overflow (no unsigned) • Unit Tests
• JavaScript sandbox escapes • Test for –n, -1, -0, 0, 1, n (where n is
huge)
• OWASP Proactive Controls C4 and C5 • Test for –n, -1, -0, 0, 1, n (where n is
huge)
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

5.5.2 Protect against XXE (and SSRF)
• Verify that the application correctly • Recommended solutions
restricts XML parsers to only use the most • Disable XML External Entities
restrictive configuration possible and to • Upgrade XML processors
ensure that unsafe features such as • Block new outbound connections from
resolving external entities are disabled to servers or only via a whitelisted proxy
prevent XXE. server
• Rationale • Monitor outbound connection attempts
• One of the most commonly exploited issues • Unit Tests
in cloud environments today • Use XXE fuzz list
• High payouts in bug bounties
• Can result in remote code execution (RCE) • End to end integration tests
• Use XXE fuzz list
• PCI DSS 6.5.1 and 6.5.7
• NIST 800-53 SI-9 SI-10 SI-15

Input validation labs
• Please complete your previous • We will resume at 9.45 am

day labs
• Input validation (<language>)


End of Day 1
DAY 2 STARTS AT 9 AM SHARP!
Standard 4.0
Day 2
TM
GLOBAL APPSEC DC
What did we learn yesterday?
Morning Afternoon
• About ASVS • V4 Access Control
• Incorporating ASVS into your • V5 Validation and Encoding
development lifecycle
• V1 Architecture
• V2 Authentication
• V3 Session Management

Agenda Day 2
Morning Afternoon
• V5 Validation and Encoding Lab • V8 Data Protection
(cont) • V8 Data Protection Lab
• V6 Cryptography at rest • V9 Communications Security

• V6 Cryptography Lab • V9 Communications Security Lab
• V7 Logging and Error Handling • V10 Malicious Code

• V8 Logging lab • V10 Malicious Code Lab

Cryptography at rest

What is Cryptography at Rest?
The club is pumping, and

someone just handed you a
secret code to get into the VIP
room. But it's all garbled.
Good cryptography ensures

peeping toms can't see what
they shouldn't see.

1.6.1 Secure Key Management Processes
• Verify that there is an explicit policy for • Recommended solutions
management of cryptographic keys and that a • Adopt a key management policy such as NIST 800-57
cryptographic key lifecycle follows a key • Ensure your application is compliant with it
management standard such as NIST SP 800-57.
• Rationale • Review key management documentation and processes
• Static never changing keys become ever more difficult • Sample some of the keys to see if they have been
to change managed in accordance with the policy
• Dynamic keys are still difficult to manage and change
(certificates anyone?)
• The lack of a defined key management process leads to
expired keys and certificates, outages
• Easy decryption due to the use of old keys and
algorithms
• OWASP Top 10 A3
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28

1.6.2 Store keys securely
• Verify that consumers of • Recommended solutions
cryptographic services protect key • Use the OS supplied key store
material and other secrets by using • Use a cloud key store
key vaults or API based • Use a HSM
alternatives.
• Rationale • Review how and where keys are
• Attackers who have local access will stored
also then have access to all your data • Keys should be stored in a key vault
• Relevant standards • Keys should not be on the disk or in
configuration files
• OWASP Top 10 A3 • If keys are stored in the main database,
• OWASP Proactive Controls C8 there should be some level of key
• PCI DSS 6.5.3 unlocking rather than direct use
• Consider multi-tenant issues – key per
• NIST 800-53 SC-13 SC-28 client, etc

1.6.3 Replaceable keys
• Verify that all keys and passwords are • Recommended solutions
replaceable and are part of a well- • Document key replacement mechanism
defined process to re-encrypt • Include functionality to remind
sensitive data. administrators to create, update,
manage, and revoke keys
• Rationale • If keys are used to encrypt data
• Static keys become a liability • Method to create or accept new key
• During breaches you have to change • Method to re-encrypt data in a timely
them immediately fashion
• Not knowing the impacts of change • Architecture Review
creates a risk to business recovery
• Ensure keys used within the application
• Relevant standards can be revoked and replaced
• OWASP Top 10 A3 • Ensure that data encrypted with a
• OWASP Proactive Controls C8 previous key can be re-encrypted
• PCI DSS 6.5.3 • Multi-tenant consideration of a key per
• NIST 800-53 SC-13 SC-28 client

6.1.1 Encrypt regulated data at rest
• Verify that regulated private data is • Recommended solutions
stored encrypted while at rest, such as • Review local regulations to determine what
personally identifiable information (PII), you must (or more likely - should) encrypt
sensitive personal information, or data • Encrypt at least personal health information
assessed likely to be subject to EU's • Remove data as soon as its no longer
GDPR. needed
• Required by PCI DSS, HIPPA, GDPR • Create a record containing test regulated
• Prevents data breaches using offline data
storage, SQL dumps, backups from releasing • Persist the record
any information • Retrieve the record directly from the data
• Relevant standards layer. It should not be plain text
• OWASP Proactive Controls C8 • Not applicable
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28

6.1.2 Encrypt health data
• Verify that regulated health data is stored • Recommended solutions
encrypted while at rest, such as medical • Review local regulations to determine what you
records, medical device details, or de- must encrypt
anonymized research records. • Encrypt at least personal health information
• Rationale • Remove data as soon as its no longer needed
• Some of the most sensitive data held • Unit Tests
• Breaches often lead to negative outcomes for • Create a record containing test regulated data
patients and huge fines • Persist the record
• Relevant standards • Retrieve the record directly from the data layer.
• HIPPA Security Rule covers PHI, but does not It should not be plain text
mandate encryption • End to end integration tests
• GDPR – covers PHI, but does not mandate • Not applicable
encryption but talks about it extensively
• OWASP Top 10 A3
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28

6.2.1 Fail securely
• Verify that all cryptographic • Recommended solutions
modules fail securely, and errors • If an exception or error is raised,
are handled in a way that does not securely free any partially or fully
enable Padding Oracle attacks. decrypted data
• Exceptions and errors should not • Create a test record
result in decryption or plain text • Retrieve the record and try to decrypt
it
• Relevant standards • Force an error
• OWASP Top 10 A3 • Show that error handling clears the
• OWASP Proactive Controls C8 plain text of the secure record
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28 • End to end integration tests
• Not applicable

6.2.2 Use secure, approved algorithms
• Verify that industry proven or • Recommended solutions
government approved cryptographic • Implement cryptographic agility (see
algorithms, modes, and libraries are slides coming up)
used, instead of custom coded • Review existing cryptography algorithms
cryptography. C8 and modes
• Migrate from old, broken to new
• Rationale algorithms that will last for 5+ years
• Old algorithms are either completely
broken (RC4, DES, 3DES, MD5, SHA1) or • Unit Tests
close to it (SHA256, etc) • In unit tests testing crypto using old or
• FPGA and GPU crackers deprecated algorithms, the unit test
should fail to help weed out that code
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28

6.2.3 Use secure advice for crypto defaults
• Verify that encryption initialization vector, cipher • Recommended solutions
configuration, and block modes are configured securely using • Review your crypto framework’s documentation for the latest
the latest advice. advice
• 6.2.5 Verify that known insecure block modes (i.e. ECB, etc.), • Search if this is still solid advice (hint: it’s usually not)
padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small • Ask for help from professional cryptographers if in doubt
block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing
algorithms (i.e. MD5, SHA1, etc.) are not used unless required • Unit Tests
for backwards compatibility. • Same as 6.2.2
• Advice on cryptographic algorithms, modes, and hashes rapidly • Not applicable
changes
• Old advice is likely completely out of date
• Most infosec professionals don’t keep up with current
standards
• OWASP Top 10 A3
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28

6.2.4 Cryptographic agility
• Verify that random number, • Recommended solutions
encryption or hashing algorithms, key • Implement cryptographic agility
lengths, rounds, ciphers or modes, can • Plan for re-encrypting / re-hashing all
be reconfigured, upgraded, or encrypted data
swapped at any time, to protect • Unit Tests
against cryptographic breaks.
• Change keys or algorithms
• Rationale • Re-encrypt data
• Cryptographic breaks improves over time, • Ensure that Plaintext B is the same as
algorithms don’t Plaintext A
• OWASP Top 10 A3 • Should be behind the scenes
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28

6.2.6 Secure initiatialization vectors
• Verify that nonces, initialization vectors, • Recommended solutions
and other single use numbers must not • Review crypto framework on choosing a
be used more than once with a given solid IV. Usually it’s just a random number
encryption key. The method of generation • Generate a secure random bag of bytes
must be appropriate for the algorithm • Secure the IV in configuration or in a HSM
being used. • Don’t commit IV’s to code
• Debian SSH breach • Retrieve the IV
• Static IVs (i.e. array of nulls are predictable) • Encrypt a known value
• Relevant standards • Decrypt the result with the IV
• OWASP Top 10 A3 • Ensure the known value and plain text are
• OWASP Proactive Controls C8 the same
• NIST 800-53 SC-13 SC-28 • Not applicable

6.3.1 Use a secure random number
generator
• Verify that all random numbers, random file • Recommended solutions
names, random GUIDs, and random strings are • Use SecureRandom or the equivalent on your platform
generated using the cryptographic module's • Seed it with as many sources of entropy as you can
approved cryptographically secure random number muster (some processors have instructions, such as
generator when these random values are intended RDRAND, that can help)
to be not guessable by an attacker. • TPM 1.2 chips can assist with obtaining seed values
• Rationale • Secure PRNGs will run a system out of entropy if
overused, and some block until entropy returns
• Many random implementations are not particularly
random (just fast) • Unit Tests
• Often, seeding is deterministic or static • Generate 10,000 random numbers
• Attackers might be able to generate the same seed and • Check the entropy (randomness) to determine if the
replicate the result (such as initial and password reset random values are sufficiently random
emails)
• Relevant standards • Not applicable (could potentially obtain a similar
• OWASP Top 10 A3 number of values and try to recover the seed, but this
• OWASP Proactive Controls C8 is difficult and not easily replicable in an automated
test)
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28

6.3.2 Generate GUIDs and UUIDs securely
• Verify that random GUIDs are created • Recommended solutions
using the GUID v4 algorithm, and a • Review crypto library implementation of
cryptographically-secure pseudo-random GUID / UUID implementation
number generator (CSPRNG). GUIDs • If there are fast or secure alternatives, use
created using other pseudo-random the secure version
number generators may be predictable. • Unit Tests
• Rationale • Generate 1,000 random GUIDs / UUIDs
• GUIDs are only guaranteed to be system • Check the entropy (randomness) to
unique – attackers might be able to determine if the random values are
generate new same GUIDs on a different sufficiently random
system
• OWASP Top 10 A3
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28

6.4.1 Secure secrets management
• Verify that a secrets management • Recommended solutions
solution such as a key vault is used • Use the operating system key store or
to securely create, store, control a HSM is in use
access to and destroy secrets. • Store secrets and keys in a secure key
store
• Rationale • JKS bootstrapped using a secure OS
• Storing keys in code or apps key store or HSM is acceptable
• Storing keys in plaintext in config files
• Static keys in every installation • Unit Tests
• Not applicable
• PCI DSS 6.5.3
• NIST 800-53 SC-13 SC-28

V6 Stored Crypto Lab
Error handling and logging
TM
GLOBAL APPSEC DC
What is Error Handling and Logging?
You've just bumped into

someone and spilt your drink on
them and blurted out your bank
account details by mistake. In the
confusion, you didn't write their
number down correctly to clean
their clothes.
Errors should be helpful but not

too helpful.
1.7.1 Common logging format
• Verify that a common logging • Recommended solutions
format and approach is used across • Use a common logging format
the system. • Unit Tests
• Permit faster response time to • End to end integration tests
events, triage and escalation
• Allow non-security systems such as • Not applicable
Splunk or ELK to assist with
monitoring and escalation
• OWASP Top 10 A10
• PCI DSS 6.5.5
• NIST 800-53 AU-12

1.7.2 Secure log analysis and storage
• Verify that logs are securely • Recommended solutions
transmitted to a preferably remote • Allow log shipping to other systems
system for analysis, detection, • Log to secured logs outside of the
alerting, and escalation. webroot, owned by different users
• Altering or deleting logs to cover • Not applicable
tracks is a common attacker tactic
• PCI DSS 6.5.5
• NIST 800-53 AU-6

7.1.1 Don’t log sensitive stuff
• Verify that the application does not • Recommended solutions
log credentials or payment details. • Log masked values or truncated
Session tokens should only be values if you must
stored in logs in an irreversible, • Log these only in debug mode
hashed form. • Prod builds shouldn’t be able to use
debug mode
• Rationale
• Logs become highest value data • Unit Tests
assets • Create log events such as during
authentication or failed access control
• Relevant standards • Test logs do not contain test user
• OWASP Top 10 A10 password, session ID, or any sensitive
• OWASP Proactive Controls C9 info
• NIST 800-53 AU-3 • Not applicable

7.1.2 Don’t log PII
log other sensitive data as defined • Don’t log PII
under local privacy laws or relevant • At worst, mask or truncate
security policy. • Unit Tests
• Rationale • Create, alter or delete records that
• Hard “No” from privacy regulations might contain PII
• Review logs to ensure PII is not
• Relevant standards logged
• OWASP Top 10 A3 A10
• PCI DSS 6.5.5 • Create, alter or delete records that
contain PII
• NIST 800-53 AU-3
7.1.3 Log security relevant events
• Verify that the application logs • Recommended solutions
security relevant events including • Log authentication, access control, high
successful and failed authentication value business logic and other relevant
events, access control failures, events to allow reconstruction of
deserialization failures and input attacker’s activities
validation failures. • Unit Tests
• Rationale • Generate security relevant errors
• Attackers rely and love systems that don’t • Check logs contain sufficient logging
log or audit anything • Check logs don’t contain PII
• OWASP Top 10 A10 • Generate security relevant activities
• PCI DSS 6.5.5
• NIST 800-53 AU-2

7.1.4 Timeline reconstructcion
• Verify that each log event includes • Recommended solutions
necessary information that would allow • Log events with sufficient information and
for a detailed investigation of the timeline accurate time stamps
when an event happens. • Unit Tests
• Rationale • Create errors
• Attackers who cross multiple channels / • Ensure logs contain sufficient information
streams rely on the lack of timeline and accurate timestamps
reconstruction
• Breach detection relies on timeline • End to end integration tests
reconstruction to determine other • Create errors
compromised systems
• PCI DSS 6.5.5
• NIST 800-53 AU-6 AU-7

7.2.1 Log authentication events
• Verify that all authentication • Recommended solutions
decisions are logged, without • Always log failed logins
storing sensitive session identifiers • Log successful logins per admin
or passwords. This should include requirement
requests with relevant metadata • Unit Tests
needed for security investigations. • Test logging of failed logins
• Rationale • Test optional logging of granted logins
• Allows detection of brute force, • End to end integration tests
credential stuffing, and other attacks
• Test failed logins
• Relevant standards • Test permitted logins
• OWASP Top 10 A10 • Review logs to ensure that log events
• OWASP Proactive Controls C9 were generated
• PCI DSS 6.5.5
• NIST 800-53 AU-4

7.2.2 Log access control decisions
• Verify that all access control • Recommended solutions
decisions can be logged and all • Log failed access control decisions
failed decisions are logged. This always
should include requests with • Log permitted access control
relevant metadata needed for decisions based upon admin config
security investigations. • Unit Tests
• Rationale • Test failed access – was log created?
• Allow detection of horizontal and • Test granted access – was log created
vertical privilege escalation attacks if logging enabled?
• OWASP Top 10 A10 • Generate failed and granted access
• OWASP Proactive Controls C9 control decisions
• PCI DSS 6.5.5
• NIST 800-53 AU-4

7.3.2 Prevent log injection
• Verify that all events are protected • Recommended solutions
from injection when viewed in log • Escape any user supplied input
viewing software. • Don’t use HTML in logs unless
• Rationale required
• Log injection – HTML attacks • Unit Tests
• Log injection – integrity attacks • Not applicable
• Log injection – non-repudiation • End to end integration tests
attacks
• Not applicable
• PCI DSS 6.5.5
• NIST 800-53 AU-4

7.3.3 Protect security logs and systems
• Verify that security logs are • Recommended solutions
protected from unauthorized • Log ship where possible
access and modification. • Log to the system logs where the
• Rationale application framework can’t alter the
logs
• Don’t let attackers wipe or alter
history • Unit Tests
• Allows reliable monitoring, triage and • Try to alter or delete log files
escalation • End to end integration tests
• Allows prosecutions to proceed
• Not applicable
• PCI DSS 6.5.5
• NIST 800-53 AU-9

7.3.4 Synchronized clocks
• Verify that time sources are • Recommended solutions
synchronized to the correct time and • Make life simple. Use UTC for servers
time zone. Strongly consider logging • Run NTP (default for ~100% of OSs today)
only in UTC if systems are global to
assist with post-incident forensic • Unit Tests
analysis. • Not applicable
• Timeline reconstruction is impossible • Not applicable
without this
• Pretty much standard today
• PCI DSS 6.5.5
• NIST 800-53 AU-8

7.4.1 User actionable error messages
• Verify that a generic message is shown • Recommended solutions
when an unexpected or security sensitive • Implement custom error messages
error occurs, potentially with a unique ID • Log dev ready content to logs
which support personnel can use to • Gather consent, and fire them at Jira or
investigate. GitHub Issues or something commercial like
• Rationale a diagnostics services
• Most users can’t fix your code • Unit Tests
• Attackers love detailed errors and • Ensure that detailed errors do not contain
exceptions sensitive info
• Older platforms exposed a lot of info • Send them off to some form of analysis
• Debug consoles are a thing service if consent is granted
• OWASP Top 10 A10 • Force errors or similar to trigger logs to
analysis services
• OWASP Proactive Controls C10 • Errors should not be detailed
• PCI DSS 6.5.5 • Errors should be actionable by the user
• NIST 800-53 AU-4

7.4.2 Do exceptions or error handling
• Verify that exception handling (or a • Recommended solutions
functional equivalent) is used across • Choose one way or the other
the codebase to account for expected • Be consistent in your handling
and unexpected error conditions.
• Unit Tests
• Rationale • Trigger errors as often as possible
• Not doing it allows attackers a free pass
• Exceptions required for Java, others
• Trigger errors as often as possible
• Errors for Go, others
• PCI DSS 6.5.5
• NIST 800-53 AU-4

7.4.3 Last resort error handler
• Verify that a "last resort" error • Recommended solutions
handler is defined which will catch • Have a high level handler for things
all unhandled exceptions. you won’t handle, like out of memory
or no more threads
• Rationale • Decide on a tactic to deal with this
• Sometimes panic() is an ok response • Kill the container
• Other times, “turn it off and on • Restart the app
again” • Regularly reboot
• OWASP Top 10 A10 • Not applicable
• PCI DSS 6.5.5
• Not applicable
• NIST 800-53 AU-4

Error Handling and
Logging Lab
SECURE CODE WARRIOR
Data protection

What is Data Protection?
Writing your home address and

phone number on the toilet wall
might not the best idea you've
had.
Data protection is about ensuring

sensitive data is stored and
handled in a secure way

Notable Hacks
So many buckets...
• The U.S. defense contractor left
data publicly accessible through
an insecurely configured S3
account containing files related
to the National Geospatial-
Intelligence Agency (NGA), which
handles battlefield satellite and
drone imagery

8.1.1 Sensitive data caching
• Verify the application protects sensitive • Recommended solutions
data from being cached in server • Design the application that treats front end
components such as load balancers and caching and other systems as the public
application caches. Internet
• Use TLS between these components
• Rationale
• Design URLs and APIs in a way that limits
• Server components such as load balancers, data caching in logs and server(less) state
CDNs and so on become valuable targets
• Establish configuration that limits retention
• Likely you do not have visibility of breaches and storage
at this layer
• Relevant standards • Architectural Review
• Review the design of CDNs, front end
• OWASP Top 10 A3 accelerators, web farms, server-less
• OWASP Proactive Controls C8 functions, and so on
• PCI DSS 6.5.3 (if related to crypto) • Determine if those components log or
• NIST 800-53 SC-28 cache data
• Determine any retention periods or if it can
be disabled

8.1.2 Purge cached copies
• Verify that all cached or temporary copies • Recommended solutions
of sensitive data stored on the server are • Caches are awesome, but have a method to
protected from unauthorized access or eliminate cached copies for sensitive data,
purged/invalidated after the authorized such as immediately after logout or idle
user accesses the sensitive data. timeouts
• Caches are rarely monitored • Test caching mechanism purges sensitive
data
• Often have high value / recent items
• LRU purges might be too infrequent • End to end integration tests
• Not applicable
• OWASP Top 10 A3
• PCI DSS 6.5.3 (if related to crypto)
• NIST 800-53 SC-28

8.1.3 Minimize request data
• Verify the application minimizes the number • Recommended solutions
of parameters in a request, such as hidden • Review design choices where requests have
fields, Ajax variables, cookies and header more than approximately 20 or so parameters
values. • Parameters users can’t see or change and are
unused on the front end shouldn’t be on the
• Rationale client
• The browser is not a safe place for state
• More parameters requires more input validation • Unit Tests
• It’s difficult to functionally test hidden values • In routers and controllers, warn if the number of
without Selenium / specialist tools parameters is large
• Attackers only need a single missed or ineffective • Ensure any large request is fully and extensively
validation validated, concentrating on hidden /
unchangeable values
• OWASP Top 10 A3 • Ensure that parameters that users cannot see or
• OWASP Proactive Controls C8 change are fully tested
• PCI DSS 6.5.3 (if related to crypto) • Work with security folks to determine additional
• NIST 800-53 SC-28 integration fuzz tests that make sense for
parameters that cannot be easily functionally
tested

8.1.4 Alert on high numbers of requests
• Verify the application can detect and alert • Recommended solutions
on abnormal numbers of requests, such • Keep tabs on relevant accesses
as by IP, user, total per hour or day, or • Alert above certain thresholds
whatever makes sense for the • Review OWASP Automation for guidance
application.
• Unit Tests
• Rationale • Test high value transactions for aggregate
• Breaches and exfil requires mass record alerting
access • Attempt to use extensively
• Relevant standards • Attempt to use quickly
• OWASP Top 10 A3 • Mock multiple source IP addresses Mock
multiple source IP addresses
• OWASP Proactive Controls C8 • Attempt to access others’ data
• NIST 800-53 SC-28 • End to end integration tests
• Access 10,000 records or try to register
hundreds of accounts
• Ensure that alerts have been issued

8.2.1 Anti-caching headers
• Verify the application sets • Recommended solutions
sufficient anti-caching headers so • Configure the app server to issue
that sensitive data is not cached in anti-caching headers for responses
modern browsers. with sensitive data
• Shared browsers • If manually constructing headers, test
that response headers contain
• Browser extensions (to some degree)
• Check that the response header
• OWASP Top 10 A3 contains appropriate anti-caching
• OWASP Proactive Controls C8 headers for sensitive data
• PCI DSS 6.5.3 (if related to crypto) • Images and assets shared by all users,
• NIST 800-53 SC-28 JS, etc can be cached if desired

8.2.2 Protect stored client-side sensitive
data
• Verify that data stored in client-side • Recommended solutions
storage (such as HTML5 local storage, • Minimize stored client-side sensitive data
session storage, IndexedDB, regular • Consider using encryption to make it
cookies or Flash cookies) does not slightly more difficult to view
contain sensitive data or PII. • Turtles all the way down
• Local Storage is just another database • Not applicable
• Easily hacked by a local attacker • End to end integration tests
• Typically a SQL Lite database • Create a sensitive record that will end up
• Relevant standards in local client storage
• OWASP Top 10 A3 • Retrieve it directly
• OWASP Proactive Controls C8 • Plaintext – fail
• If it needs protection, does it belong?
• NIST 800-53 SC-28

8.2.3 Clear client-side data upon logout
• Verify that authenticated data is • Recommended solutions
cleared from client storage, such as • Web Sockets – push deletion during
the browser DOM, after the client logout
or session is terminated. • Idle timeouts on client side – delete
sensitive data, invoke server side
• Rationale logout
• Shared browsers
• Browser extensions Browser • Unit Tests
extensions • Not applicable
• OWASP Top 10 A3 • Idle out – should be no more
• OWASP Proactive Controls C8 sensitive data locally
• PCI DSS 6.5.3 (if related to crypto) • Logout out – should be no more
sensitive data locally
• NIST 800-53 SC-28

8.3.1 Send sensitive data in request body
• Verify that sensitive data is sent to the • Recommended solutions
server in the HTTP message body or • Credentials, PII, credit cards PANs, or
headers, and that query string other sensitive information in URL
parameters from any HTTP verb do parameters or headers should be sent in
not contain sensitive data. the HTTP body, not in the URL or headers
• Data in GET requests can be found in • Review any API that requires sensitive
browser history and logs outside of your data in the URL
system • Fail the test
• Remove the API method / URL route
• OWASP Proactive Controls C8 • Per the unit tests
• NIST 800-53 SC-28

8.3.2 Rights to be forgotten and data
takeout
• Verify that users have a method to • Recommended solutions
remove or export their data on • Provide a data take out feature
demand. • Provide a “right to be forgotten” feature that
fully removes all data
• Rationale • Ensure that data take out and account deletion is
heavily protected to prevent unauthorized
• Required by GDPR disclosure or data destruction
• If you have any users in the EU, you • Unit Tests
are also subject to the GDPR • Test data takeout
• Users now expect these features • As the current user
• Attempt to download someone else’s takeout
• Relevant standards • Test data deletion
• OWASP Top 10 A3 • As the current test user – all data should be removed
including the account.
• OWASP Proactive Controls C8 • As another user – should not be possible
• PCI DSS 6.5.3 (if related to crypto) • End to end integration tests
• NIST 800-53 SC-28 • Per unit tests

8.3.3 Data collection and privacy policies
• Verify that users are provided clear language • Recommended solutions
regarding collection and use of supplied • Consider Australian Privacy Principles 11 –
personal information and that users have technical controls
provided opt-in consent for the use of that • Choose a privacy standard that meets or exceeds
data before it is used in any way. your local regulations
• Rationale • Implement the requirements from this privacy
standard
• Firms that are unaware of privacy regulations are • Conduct a privacy impact analysis
likely to suffer breaches
• Most privacy regulations require linked privacy • Architecture Review
policies, and for apps to actually implement • Review privacy policies in light of local privacy
• Relevant standards regulations
• OWASP Top 10 A3 • Consider if the app is likely to have users subject
to GDPR
• OWASP Proactive Controls C8 • Consider if the policies and procedures are
• PCI DSS 6.5.3 (if related to crypto) implemented by the application
• NIST 800-53 SC-28

8.3.5 Audit sensitive data access
• Verify accessing sensitive data is audited • Recommended solutions
(without logging the sensitive data itself), if • Accessing high value records should be recorded
the data is collected under relevant data • High value (and preferably all) transactions
protection directives or where logging of should be auditable
access is required. • Ensure audit records don’t contain sensitive
• Rationale elements
• Breach monitoring is not possible without audit • Unit Tests
trails • Perform high value transaction. An audit record
• Relevant standards should be created
• OWASP Top 10 A3 • Access high value data. An audit record should
be created
• PCI DSS 6.5.3 (if related to crypto) • End to end integration tests
• NIST 800-53 SC-28 • Perform a high value transaction, change the
user’s state, and access sensitive information
Perform a high value transaction, change the
user’s state, and access sensitive information
• Review audit records Review audit records

8.3.6 Overwrite sensitive data memory
• Verify that sensitive information • Recommended solutions
contained in memory is • Use byte arrays in languages without
overwritten as soon as it is no secure string support
longer required to mitigate • Zero out byte arrays and then free
memory dumping attacks, using them
zeroes or random data. • Unit Tests
• Rationale • Dump process memory after a
• Mimikatz and metasploit sensitive record is freed
• Determine if the sensitive data is
• Relevant standards within the memory dump
• Not applicable
• NIST 800-53 SC-28

8.3.7 Encrypt sensitive data
• Verify that sensitive or private • Recommended solutions
information that is required to be • Ensure PII/PHI/regulated data is
encrypted, is encrypted using encrypted
approved algorithms that provide • Unit Tests
both confidentiality and integrity. • Create a sensitive record
• Rationale • Retrieve it
• Data breaches are a thing • Should not be plaintext
• Protects against db dumps and backup • End to end integration tests
exfil
• Don’t make life easy for attackers • Not applicable
• OWASP Top 10 A3
• NIST 800-53 SC-28

8.3.8 Implement data retention (deletion)
policy
• Verify that sensitive personal information is • Recommended solutions
subject to data retention classification, such • Implement age limits for all sensitive data
that old or out of date data is deleted • If the business requires sensitive data to be kept longer than
the retention period, allow clients to renew your relationship
automatically, on a schedule, or as the with you or build in additional protection If the business
situation requires. requires sensitive data to be kept longer than the retention
period, allow clients to renew your relationship with you or
build in additional protection
• Rationale • Allow users to do a data takeout and the right to be forgotten
• Stale data is useless • Unit Tests
• Stale data is a negative data asset with costs and • Test in date data
no benefits • Test data takeout
• Some data, such as bank client info is collected • Should contain all current records
at opening, and may need to exist for 100+ years • Test data retention (deletion)
• Be aware of data retention deleting such data • Test right to be forgotten
• OWASP Top 10 A3 • Create sensitive data
• Age it sufficiently to be subject to data retention
• OWASP Proactive Controls C8 • Determine if the application expires and clears out this “aged”
• PCI DSS 6.5.3 (if related to crypto) data
• NIST 800-53 SC-28

Data Protection Lab
V9 Communications security
TM
GLOBAL APPSEC DC
What is Communications Security?
• Secure communications provides

• Confidentiality
• Integrity
• Makes it harder for an attacker

• Sniff / disclose sensitive traffic
• Fabricate high value transactions
This Photo by Unknown Author is licensed under CC BY-NC

Some past breaches
Google data center backbones
Zero Trust
British Airways
Unencrypted links expose PII

9.1.1 Only expose encrypted end points
• Verify that secured TLS is used for • Recommended solutions
all client connectivity and does not • Only configure encrypted end points
fall back to insecure or • Set up redirection or preferably
unencrypted protocols. disable unencrypted end points
• Unencrypted end points can result in • Not applicable
sensitive information disclosure
• Relevant standards • Try making connections with
• OWASP Top 10 A3 unencrypted end points
• OWASP Proactive Controls C8 • Should fail (to connect)
• PCI DSS 6.5.4
• NIST 800-53 SC-8 • Make connections with encrypted
end points
• Should (connect) pass

9.1.2 Use well known TLS configuration
tools
• Verify using online or up to date TLS • Recommended solutions
testing tools that only strong • AWS ELB latest profile
algorithms, ciphers, and protocols are • Mozilla Developer Network TLS
enabled, with the strongest Configuration Tool
algorithms and ciphers set as • Qualys SSL Labs
preferred. • Unit Tests
• Get a strong and compatible
configuration first time • End to end integration tests
• Why try harder • Not applicable
• OWASP Top 10 A3
• PCI DSS 6.5.4
• NIST 800-53 SC-8

9.1.3 Strong TLS Configuration
• Verify that old versions of SSL and TLS • Recommended solutions
protocols, algorithms, ciphers, and • Use AWS ELB
configuration are disabled, such as SSLv2, • Use Mozilla Developer Network TLS config
SSLv3, or TLS 1.0 and TLS 1.1. The latest • Use Qualys SSL Labs
version of TLS should be the preferred cipher
suite. • Unit Tests
• Old ciphers and algorithms have known • End to end integration tests
weaknesses • Not applicable
• Modern crypto attacks coupled with modern
GPUs and FPGAs = sufficiently close to magic
• OWASP Top 10 A3
• PCI DSS 6.5.4
• NIST 800-53 SC-8

9.2.1 Use trusted certificates
• Verify that connections to and from the • Recommended solutions
server use trusted TLS certificates. Where • Let’s encrypt
internally generated or self-signed certificates • Commercial certificates
are used, the server must be configured to • Self-signed certificates
only trust specific internal CAs and specific
self-signed certificates. All others should be • Unit Tests
rejected. • Not applicable
• Attackers have to jump > < this high to intercept • Try making connections with unencrypted end
or man-in-the-middle communications points
• Let’s encrypt is free, commercial certs are cheap, • Should fail (to connect)
self signed is free but heavy management
• Relevant standards • Make connections with encrypted end points
• OWASP Top 10 A3 • Should (connect) pass
• PCI DSS 6.5.4
• NIST 800-53 SC-8

9.2.2 Encrypt all connections
• Verify that encrypted communications such as • Recommended solutions
TLS is used for all inbound and outbound • Ensure all internal connections use TLS, database
connections, including for management ports, encryption, SSH, etc
monitoring, authentication, API, or web • Unit Tests
service calls, database, cloud, serverless,
mainframe, external, and partner • Not applicable
connections. The server must not fall back to • End to end integration tests
insecure or unencrypted protocols. • Try making connections with unencrypted end
• Rationale points
• Don’t trust cloud or internal infrastructure • Should fail (to connect)
• Stop attackers from sniffing sensitive comms
• Make connections with encrypted end points
• Relevant standards • Should (connect) pass
• OWASP Top 10 A3
• PCI DSS 6.5.4
• NIST 800-53 SC-8

9.2.3 Authenticate B2B connections
• Verify that all encrypted connections to external • Recommended solutions
systems that involve sensitive information or • Use JWT or oAuth authentication for RESTful API
functions are authenticated. • Use SAML or similar for SOAP requests
• Rationale • Database: use your DBMS authentication
• Unauthenticated internal connections, such as old EJB / • Unit Tests
internal API aren’t really internal if someone pops a
shell • Not applicable
• Unauthenticated API are subject to SSRF and XXE • End to end integration tests
discovery
• Test without any cookies, API keys or JWT tokens
• Relevant standards • Should fail
• OWASP Top 10 A3
• OWASP Proactive Controls C8 • Test with in-session token
• PCI DSS 6.5.4 • Should pass
• NIST 800-53 SC-8
• Test with expired token
• Should fail
• Test with revoked token

• Should fail

SSLUseStapling on|off
9.2.4 Configure OCSP stapling

• Verify that proper certification • Recommended solutions
revocation, such as Online • Configure OSCP stapling
Certificate Status Protocol (OCSP) • Apache SSLUseStapling on
Stapling, is enabled and configured. • Nginx ssl_stapling on;
ssl_stapling_verify on;
• Rationale • Windows 2008+ enabled by default
• Prevents clients trusting old dodgy
certs that might have been exposed • Unit Tests
• Not applicable
• PCI DSS 6.5.4
• NIST 800-53 SC-8

Cryptography demo
and labs
MOZILLA DEVELOPMENT NETWORK – LET ’S BUILD A SERVER CONFIG
SSL LABS – LET ’S ANALYZE A SITE
SECURE CODE WARRIOR
V10 Malicious Code
TM
GLOBAL APPSEC DC
What is Malicious
Code?
Code inserted by insiders or partners or
suppliers that:
Performs unauthorized activities
Harms the organization or its users
Discloses sensitive information
Deletes, corrupts or encrypts data for
ransom

Some past breaches
• Google Android 100m+ installs
- Malicious ad network
- WebMin Backdoor
- Fortinet Backdoor
- Goto Fail (SSL bypass)

- Linux root login
This Photo by Unknown Author is licensed under CC BY-NC-ND
- NAB Time Bomb

10.1.1 Static code analysis tools
• Verify that a code analysis tool is in • Recommended solutions
use that can detect potentially • Use static code analysis tools
malicious code, such as time • Use dependency checkers
functions, unsafe file operations and • Review checkins
network connections. • Don’t rely on these tools – malicious code
• Rationale bridges the gap between plausible
deniability and outright badness
• Finds time based low hanging fruit
• Finds code that might be “interesting” • CI/CD Steps
• Finds out of date software • Run static code analysis tools
• Investigate changes that weren’t
• Relevant standards approved
• OWASP Top 10 N/A
• OWASP Proactive Controls N/A
• PCI DSS N/A
• NIST 800-53 SI-3

10.2.1 Phone Home Functionality
• Verify that the application source code and • Recommended solutions
third-party libraries do not contain • Review third party libraries such as analytics, ad
unauthorized phone home or data collection networks, and so on at least once before
capabilities. Where such functionality exists, inclusion
obtain the user's permission for it to operate • Include these libraries in static code analysis and
before collecting any data. dependency checks
• One of the most recent examples exploited this • Not applicable
exact issue
• Users do not expect phone home functionality
without permission • Not applicable
• PCI DSS N/A
• NIST 800-53 SI-3

10.2.2 Only ask for necessary permissions
ask for unnecessary or excessive • Design your app to be strictly sandboxed
permissions to privacy related or containerized
features or sensors, such as contacts, • Start containers with minimal
cameras, microphones, or location. connectivity
• Do not require any more permissions
• Rationale than is required for operation
• Excessive attack surface
• Lateral movement post exploitation • Unit Tests
• Living off the land • Try to use features that require additional
permissions
• Relevant standards • These should fail to be granted
• OWASP Top 10 N/A • Fail gracefully
• OWASP Proactive Controls N/A • End to end integration tests
• PCI DSS N/A • Not applicable
• NIST 800-53 SI-3

10.2.3 No backdoors
• Verify that the application source code and • Recommended solutions
third-party libraries do not contain back • Review third party libraries at least once
doors, such as hard-coded or additional • Statically review code for base64, eval, and so on
undocumented accounts or keys, code (hiding attempts)
obfuscation, undocumented binary blobs, • Static code analysis can assist with identifying
rootkits, or anti-debugging, insecure open network sockets
debugging features, or otherwise out of date, • Review all routes and controllers, particularly
insecure, or hidden functionality that could unauthenticated and high value end to end
be used maliciously if discovered.
• Unit Tests
• Backdoors are negligent and may lead to
significant legal damages (watch Fortinet) • End to end integration tests
• Difficult to determine, especially in node.js • Not applicable
• PCI DSS N/A
• NIST 800-53 SI-3

10.2.4 No time bombs
• Verify that the application source • Recommended solutions
code and third-party libraries does not • Review all code containing time functions
contain time bombs by searching for • Determine if it could be used to schedule
date and time related functions. destructive capability or has
unauthorized additional code
• Rationale
• Timebombs cause denial of service • Unit Tests
• Evade IDS sandboxes • Not applicable
• “Dead man” nuclear option • End to end integration tests
• NAB Time Bomb • Not applicable
• PCI DSS N/A
• NIST 800-53 SI-3

10.2.5 No business logic malicious code
• Verify that the application source code • Recommended solutions
and third-party libraries does not contain • Review all high value functions
malicious code, such as salami attacks, • Ensure that code implements desired
logic bypasses, or logic bombs. functionality
• Rationale • Determine if there’s additional unexplained
code
• Insider malicious code
• GOTO Fail • Source code review
• Linux root login • OS system() (OS command injection)
• OfficeSpace • Arithmetic ifs
• Null dereferences and plausible
• Improper error handling
• Base64 decode
• Eval()
• PCI DSS N/A
• Obscure code constructs
• NIST 800-53 SI-3

10.2.6 No Easter eggs
• Verify that the application source • Recommended solutions
code and third-party libraries do
not contain Easter eggs or any • Ensure there is a policy relating to
other potentially unwanted Easter eggs in your development
functionality. standards
• Rationale • Review checkins for interesting
• Easter eggs are often not well tested code
• Might have unwanted functionality
• OWASP Top 10 N/A • Not applicable
• OWASP Proactive Controls
N/A • End to end integration tests
• PCI DSS N/A • Not applicable
• NIST 800-53 SI-3
10.3.1 Auto update protection
• Verify that if the application has a • Recommended solutions
client or server auto-update feature, • Use TLS, always
updates should be obtained over • Protect and monitor distribution sites
secure channels and digitally signed. • Code sign with a secure private key
The update code must validate the
digital signature of the update before • Unit Tests
installing or executing the update. • Not applicable
• Auto update was used to destroy several • Not applicable
South Korean banks
• PCI DSS N/A
• NIST 800-53 SI-3

10.3.2 Integrity protection
• Verify that the application employs integrity • Recommended solutions
protections, such as code signing or sub- • Validate repos and dependencies before first use
resource integrity. The application must not • Always use TLS to load remote resources
load or execute code from untrusted sources, • Use sub-resource integrity (see V14)
such as loading includes, modules, plugins,
code, or libraries from untrusted sources or • Use code signing for auto-updates
the Internet. • Unit Tests
• Allowing unsigned code to run is asking for • End to end integration tests
trouble • Not applicable
• Replacement of modules by malicious actors
• PCI DSS N/A
• NIST 800-53 SI-3

10.3.3 Protect against sub-domain takeovers
• Verify that the application has protection from sub- • Recommended solutions
domain takeovers if the application relies upon
DNS entries or DNS sub-domains, such as expired
domain names, out of date DNS pointers or
• Review sub-domains you’ve used in
CNAMEs, expired projects at public source code the past or use DNS discovery tools to
repos, or transient cloud APIs, serverless functions, enumerate them
or storage buckets (autogen-bucket-
id.cloud.example.com) or similar. Protections can • Ensure your code doesn’t trust or use
include ensuring that DNS names used by them
applications are regularly checked for expiry or
change. • Adapt the design to avoid the use of
• Rationale dynamically named cloud objects
• Commonly exploited in cloud-based environments
• Unit Tests
• OWASP Top 10 N/A • Not applicable
•
•
OWASP Proactive Controls
PCI DSS
N/A
N/A • End to end integration tests
• NIST 800-53 SI-3 • Not applicable

Malicious Code Labs
CODE INJECTION, ETC THAT CAN BE USED BY A BAD ACTOR
End of Day 2
DAY 3 STARTS AT 9 AM SHARP!
Standard 4.0
September 2019
Day 3
TM
GLOBAL APPSEC DC
What did we learn yesterday?
Morning Afternoon
• V5 Validation and Encoding Lab • V8 Data Protection
(cont) • V8 Data Protection Lab
• V6 Cryptography at rest • V9 Communications Security

• V6 Cryptography Lab • V9 Communications Security Lab
• V7 Logging and Error Handling • V10 Malicious Code

• V8 Logging lab • V10 Malicious Code Lab

Agenda Day 3
Morning Afternoon
• V11 Business Logic Flaws • V13 API and Web Services
• V11 Business Logic Flaws Lab • V13 API Lab
• V12 Files and Resources • V14 Configuration

• V12 Files and Resource Lab • V14 Configuration Lab
• Capture the Flag
• References and Wrap Up

V11 Business logic flaws
TM
GLOBAL APPSEC DC
What are business logic flaws?
• Bypass business logic

• Improperly implemented
business logic
• Lack of anti-automation
• Lack of business limits

Some past breaches

1.11.2 Prevent distributed / race conditions
• Verify that all high-value business logic flows, • Recommended solutions
including authentication, session • Ensure code is thread safe
management and access control, do not share • Review any shared (static) memory structures
unsynchronized state. • Review any synchronization / locking around
• Rationale shared data where different users might share
records / memory
• Race conditions were first included in security
standards in 1976 (!) • Unit Tests
• Rarely attacked today, but will change as other • Difficult to test
vectors close out
• Destroys the integrity of your data • End to end integration tests
• Create two different users A and B
• Relevant standards • Use two different data sets (AAAA) and (BBBB)
• OWASP Top 10 N/A • Set up multiple threads testing A and B
• OWASP Proactive Controls C1 (sorta) concurrently testing the same feature
• PCI DSS 6.5.x N/A • Fail if BBBB appears in A’s results or vice versa
• NIST 800-53 N/A

1.11.3 Be thread safe
• Verify that all high-value business logic flows, • Recommended solutions
including authentication, session • Java Concurrency Checklist
management and access control are thread • Node.js – Worker Threads
safe and resistant to time-of-check and time- • Understand shared data locations
of-use race conditions. • Sources – Users, processes, uploads, etc
• Rationale • Sinks – files, memory objects, database records
• Almost all CPUs are now multi-core • Shared by multiple users?
• Most platforms pretend to be single threaded • Unit Tests
• Issue first documented in 1976 • Create two threads, one for User A and one for
User B
• Relevant standards • Test with AAAA data for User A
• Test with BBBB data for User B
• OWASP Proactive Controls C1 (sorta)
• Hammer functions that use shared state
• PCI DSS 6.5.x N/A
• Inspect cross user data pollution
• NIST 800-53 N/A
• Same as unit tests
• Potentially scale out

11.1.1 Enforce business logic sequences
• Verify the application will only • Recommended solutions
process business logic flows for the • Consider using Spring Web Flow
same user in sequential step order • State machines (State design pattern)
and without skipping steps. • Enforce flow
• Rationale • Last step validation
• Attackers can skip steps • Unit Tests
• Replay attacks • Ensure that business logic steps can
• CD Now only proceed in order
• OWASP Top 10 N/A • Ensure that business logic steps can
• OWASP Proactive ControlsC1 (sorta) only proceed in order
• NIST 800-53 N/A

11.1.2 Implement human time
• Verify the application will only process • Recommended solutions
business logic flows with all steps being • At least be able to detect automated
processed in realistic human time, i.e. scanning, fuzzing and “too fast” requests
transactions are not submitted too • OWASP Automated Threats to Web
quickly. Applications
• Attackers use tools to speed up attacks • Try to complete each step as quickly as
• Humans work slowly to ensure that they possible
don’t make a mistake • If completed within too short a time, it
should log an event
• OWASP Top 10 N/A • End to end integration tests
• OWASP Proactive Controls C1 (sorta) • Try to perform a complete business
sequence as quickly as possible
• It should not be possible to complete the
• NIST 800-53 N/A request in less than “human” time
• At the very least, a log event should be
created

11.1.3 Validate per user business limits
• Verify the application has appropriate • Recommended solutions
limits for specific business actions or • Implement business requirements
transactions which are correctly enforced • Have a safe default value
on a per user basis. • Implement extensions to these business
• Rationale limits to qualified / accredited users
• Twitter only allows 100 friends per day • Unit testing
• Banks only allow $1500 per day in transfers • Attempt to exceed business limits
• Amazon Web Services only allows 20 • Should fail
instances by default without going through
a credit check • End to end integration tests
• Attempt to exceed business limits
• NIST 800-53 N/A

11.1.4 Implement anti-automation
• Verify the application has sufficient • Recommended solutions
anti-automation controls to detect • OWASP Automated Threats to Web
and protect against data exfiltration, Applications
excessive business logic requests, • Technical controls, such as linear back off
excessive file uploads or denial of • Monitoring
service attacks. • Unit Tests
• Rationale • Ensure anti-automation triggers per
• We can’t be there to stop every attack configured limits
• Outsource to automation • End to end integration tests
• Relevant standards • Test anti-automation functions against:
• OWASP Top 10 N/A • Data downloads
• OWASP Proactive Controls C1 (sorta) • Business logic
• File uploads
• Long running activities
• NIST 800-53 N/A

11.1.5 Validate business limits
• Verify the application has business • Recommended solutions
logic limits or validation to protect • Work with business to document risk
against likely business risks or threats, tolerance
identified using threat modelling or • Implement business limits
similar methodologies. • Allow extensions for trusted partners and
users
• Rationale
• Easiest way to lose money, reputation, or • Unit Tests
shareholder value quickly • Test 0, under, business limit, over
• Many attacks occur over weekends and business limit
public holidays • End to end integration tests
• Relevant standards • Test 0, under, business limit, over
• OWASP Top 10 N/A business limit
• NIST 800-53 N/A

11.1.7 Check business logic sequence
• Verify the application monitors for • Recommended solutions
unusual events or activity from a • In each step, check that the previous step
business logic perspective. For has completed
example, attempts to perform actions • Validate each step as you go
out of order or actions which a normal • At the end, check that all steps have been
user would never attempt. completed and validated
• CD Now • Try to move forward multiple steps
• Can cause financial, reputation loss • Try to manipulate previous data
• Relevant standards • Try to jump to the end directly
• OWASP Proactive Controls C1 (sorta) • Try to move forward multiple steps
• PCI DSS 6.5.x N/A • Try to manipulate previous data
• NIST 800-53 N/A • Try to jump to the end directly

11.1.8 Detect automated attacks
• Verify the application has • Recommended solutions
configurable alerting when • Implement OWASP Automated Threat
automated attacks or unusual Handbook
activity is detected. • Unit Tests
• Rationale • Fuzz using SecLists
• Time to detect • Attack login, registration, access
• Financial losses (Target, Equifax) control, DORs, HVFs
• Pass if activity is detected
• OWASP Proactive ControlsC1 (sorta) • Fuzz using SecLists
• PCI DSS 6.5.x N/A • Attack login, registration, access
• NIST 800-53 N/A control, DORs, HVFs
• Pass if activity is detected

V12 Files and Resources
TM
GLOBAL APPSEC DC
What is Secure Files and Resources
• Files and resources includes:
• File uploads
• Malicious files
• Path traversal
• Pathnames / filename attacks
• Redirection and forwards

Some past breaches
• Any breach involving downloads

from S3 buckets or open
directories
• Facebook 210 m phone numbers
from US, UK and Vietnam
• Photo album privacy issue
(AusCert 2011)

12.1.1 Enforce a file size limit
• Verify that the application will not • Recommended solutions
accept large files that could fill up • Enforce a file size limit
storage or cause a denial of service • Unit Tests
attack. • Test files less than the limit: pass
• Rationale • Test files >= file size limit: fail
• Prevent users uploading movies, • End to end integration tests
extremely large blobs
• Test files less than the limit: pass
• Reduce risk of running out of storage
• Test files >= file size limit: fail
• Reduce cloud storage costs
• NIST 800-53 SI-3

12.1.2 Caution with extracting compressed
files
• Verify that compressed files are • Recommended solutions
checked for "zip bombs" - small input • Scan uploaded files with AV libraries
files that will decompress into huge • Be cautious of accepting compressed files
files thus exhausting file storage
limits. • Unit Tests
• Upload a zip bomb
• Rationale • Pass: rejects upload
• Zip Bombs are well known • Fail: runs out of disk space, never returns
• SecLists contains at least one • End to end integration tests
• Relevant standards • Upload a zip bomb
• NIST 800-53 SI-3 • Pass: rejects upload
• Fail: runs out of disk space, never returns
• PHP test zip:// bzip2:// zlib:// filters

12.1.3 Prevent big cloud storage bills
• Verify that a file size quota and • Recommended solutions

maximum number of files per • Implement per user file quotas
user is enforced to ensure that a • Monitor bucket / storage costs
single user cannot fill up the • Unit Tests
storage with too many files, or • Test file quota enforcement
excessively large files.
• Rationale • Upload many large files
• Attack costs of storing on cloud
• Pass: should block once limit
• Relevant standards reached
• NIST 800-53 SI-3 • Fail: allows user to go over quota

12.2.1 Check expected file contents
• Verify that files obtained from • Recommended solutions
untrusted sources are validated to • Use file or /usr/share/misc/magic to
be of expected type based on the determine the file type
file's content. • Graceful error handling
• Users can say anything is a JPG file • Test file upload functionality for:
• GIFARs • Files which are the correct type
• Files which are not correct type
• Relevant standards • Files which might crash the application
• NIST 800-53 SI-3
• Attempt to upload a file claiming to
be a supported file type, but is not

12.3.1 Path traversal
• Verify that user-submitted filename • Recommended solutions
metadata is not used directly with system • Decompose filenames and URLs
or framework file and URL API to protect • Validate all portions using positive
against path traversal. validation
• Rationale • Ensure basename and directory names are
still within your preferred storage bucket or
• Path traversal allows access to sensitive directory
files
• Consider using a walled file service
• Poor file handling leads to path traversal,
SSRF, and internal port scanning • Unit Tests
• Relevant standards • Test file metadata with hostile payloads:
• NIST 800-53 SI-3 • Path traversal filenames
• -ve, 0, n, huge sizes
• SQL injection and other payloads for file types
and so on
• Fuzz test file upload functionality using Zap
or Burp

12.3.2 User supplied file metadata might
allow local file inclusion
metadata is validated or ignored to • Decompose filenames and URLs
prevent the disclosure, creation, • Validate all portions using positive
updating or removal of local files (LFI). validation
• Rationale • Consider strongly not using supplied
metadata with OS / file API
• Path traversal
• Local file inclusion • Unit Tests
• SecLists payloads • Test file metadata with hostile payloads:
• DAST scanners • Path traversal filenames
• Relevant standards • SQL injection and other payloads for file
• NIST 800-53 SI-3 types and so on
• Fuzz test file upload functionality using
Zap or Burp

allow remote file inclusion or SSRF
metadata is validated or ignored to • Decompose filenames and URLs
prevent the disclosure or execution of • Validate all portions using positive
remote files (RFI), which may also lead validation
to SSRF. • Consider strongly not using supplied
metadata with OS / file API
• Rationale
• RFI and SSRF are well know today • Unit Tests
• Tools can easily test for RFI/SSRF • Test file metadata with hostile payloads:
• Path traversal filenames
• Relevant standards • -ve, 0, n, huge sizes
• OWASP Top 10 2017:AR • SQL injection and other payloads for file
• NIST 800-53 SI-3 types and so on
• Fuzz test file upload functionality using
Zap or Burp

lead to OS command injection
• Verify that untrusted file metadata • Recommended solutions
is not used directly with system API • Validate but do not use these values
or libraries, to protect against OS directly
command injection. • Unit Tests
• Rationale • Test file metadata with hostile
• Metadata is not easily UAT tested payloads:
• Testing tools can adjust all of these • Path traversal filenames
values • -ve, 0, n, huge sizes
• SQL injection and other payloads for
• Relevant standards file types and so on
• NIST 800-53 SI-3 • End to end integration tests
• Fuzz test file upload functionality
using Zap or Burp

12.3.6 Verified components only
include and execute functionality • Vet the source of repositories
from untrusted sources, such as • Use a dependency tracker to ensure
unverified content distribution that the latest versions are in place
networks, JavaScript libraries, node • Unit Tests
npm libraries, or server-side DLLs. • Not testable
• Untrusted libraries can compromise • Not testable
securely developed applications
• NIST 800-53 SI-3

12.4.1 Store files outside the webroot

untrusted sources are stored • Use bucket, database, directory
outside the web root, with outside the webroot, or a file store
limited permissions, preferably • Unit Tests
with strong validation. • Upload files: confirm that the
• Rationale persisted file is not within the
webroot
• Web Shells
• Malicious attachments • End to end integration tests
• Relevant standards • Not testable
• NIST 800-53 SI-3

12.4.2 Scan uploaded files
untrusted sources are scanned by • Scan files with an AV library
antivirus scanners to prevent • Send a SHA256 hash to Virus Total
upload of known malicious • Unit Tests
content.
• Upload normal file: should pass
• Rationale • Upload EICAR: should fail
• Most malware is off the shelf
• Some users are not aware they are
infected • Same as unit tests
• Custom malware is easy to produce
• NIST 800-53 SI-3

12.5.1 Permit access only to known file
types
• Verify that the web tier is configured • Recommended solutions
to serve only files with specific file • Harden web server configuration
extensions to prevent unintentional • Harden application server configuration
information and source code leakage. • Use a WAF
For example, backup files (e.g. .bak),
temporary working files (e.g. .swp), • Unit Tests
compressed files (.zip, .tar.gz, etc) and • Not applicable
other extensions commonly used by • End to end integration tests
editors should be blocked unless • Not applicable
required.
• Rationale
• Content discovery by DAST scanners
• Google Dorking
• NIST 800-53 SI-3

12.5.2 Protect uploaded files from direct
access
• Verify that direct requests to • Recommended solutions
uploaded files will never be • Place file buckets outside of the
executed as HTML/JavaScript webroot
content. • Enforce access controls
• Rationale • Allow file downloads as multi-part
octet streams
• Web shells and backdoors
• Data exfiltration • Unit Tests
• Excessive downloads • Test that users have access to files
• Test delivery of octet-streams
• Try using path traversal to the path of
the file bucket / directory: should fail

12.6.1 Implement network whitelisting
• Verify that the web or application • Recommended solutions
server is configured with a whitelist • Use a positive network filter for new
of resources or systems to which outbound connections
the server can send requests or • If you don’t need outbound
load data/files from. connectivity, don’t allow outbound
• Rationale • Monitor outbound connection
attempts
• Attackers expect easy exfiltration
• Most firewalls are strict inbound • Unit Tests
• Most firewalls are lax outbound • Try to make an unauthorized
connection to an external resource
• Same as unit tests, using SSRF or
similar attack

Files and Resources Lab
V13 Web Services Security
TM
GLOBAL APPSEC DC
What is Web Service Security
• RESTful, server-less (functions),

and SOAP based security
• Covers primarily REST

• SOAP still very prevalent in ESBs
and large enterprises
• WS-Security* solves a lot of open

problems in RESTful security

Some past breaches
Venmo API breach
7 m transactions
Lenovo / EMC storage API

36 TB of files exposed
Shopify
Thousands of stores
revenue data exposed
This Photo by Unknown Author is licensed under CC BY-SA-NC

13.1.1 Protect against SSRF and RFI
• Verify that all application components • Recommended solutions
use the same encodings and parsers • Decompose filenames and URLs
to avoid parsing attacks that exploit • Validate all portions using positive
different URI or file parsing behavior validation
that could be used in SSRF and RFI • Consider strongly not using supplied
attacks. metadata with OS / file API
• SSRF and RFI are well known • Test file metadata with hostile payloads:
• Easily tested using OWASP Zap or Burp • Path traversal filenames
• Relevant standards • SSRF, RFI, SQL injection and other payloads
• OWASP Top 10 (all of it) for file types and so on
• OWASP Proactive Controls (all of it) • End to end integration tests
• PCI DSS 6.5.* (most of it) • Fuzz test file upload functionality using
• NIST 800-53 AC SI SC SA IA CM Zap or Burp, especially for SSRF and RFI

13.1.2 Administrator access control
• Verify that access to administration • Recommended solutions
and management functions is • Admin API should require MFA
limited to authorized authentication
administrators. • Ensure that administration API is
enforcing RBAC for admins
• Rationale
• Access control is about who you are, • Unit Tests
not where you are • Try to use admin API:
• Internal, unmaintained applications • Anonymous users: fail
provide false sense of security • Normal non-MFA user: fail
• Normal user with MFA: fail
• Relevant standards • Administrator w/out MFA: fail
• OWASP Top 10 (all of it) • Administrator with MFA: pass
• OWASP Proactive Controls (all of it)
• PCI DSS 6.5.* (most of it) • End to end integration tests
• NIST 800-53 AC SI SC SA IA CM • Same as unit tests

13.1.3 API keys not in URLs
• Verify API URLs do not expose • Recommended solutions
sensitive information, such as the • JWT, SAML, OAuth
API key, session tokens etc. • Unit Tests
• Rationale • If any API takes an URL API Key
• API keys are the same as username + parameter:
password • Warn if many such functions
• Error (break the build) if few
• OWASP Top 10 (all of it) • End to end integration tests
• OWASP Proactive Controls (all of it) • Same as Unit tests
• PCI DSS 6.5.* (most of it)
• NIST 800-53 AC SI SC SA IA CM

13.1.4 Access control on trusted layers
• Verify that authorization decisions • Recommended solutions
are made at both the URI, enforced • Use JWT, SAML assertions
by programmatic or declarative • Enforce at the controller, and at
security at the controller or router, relevant layers
and at the resource level, enforced • Unit Tests
by model-based permissions. • Accessing the API: router/controller
• Rationale • Accessing specific records: model
• Access controls can be bypassed • Accessing business logic: domain
outside of trusted service layers
• Relevant standards • Test for anonymous users, users
• OWASP Top 10 (all of it) without the sufficient roles, and users
• OWASP Proactive Controls (all of it) with sufficient privileges

13.2.1 RESTful methods correctly used
• Verify that enabled RESTful HTTP • Recommended solutions
methods are a valid choice for the • Ensure for languages where there is
user or action, such as preventing no distinction between GPCES, that
normal users using DELETE or PUT the method is used to distinguish
on protected API or resources. privileges actions (POST, PUT, DELETE)
• Bypass access controls • Try to delete records using ~ DELETE
• GET should not act as PUT or DELETE • Try to create new records using ~ PUT
• Try to modify records using ~ POST
• Relevant standards • Try to get records using ~ GET
• OWASP Top 10 (all of it)
• OWASP Proactive Controls (all of it) • End to end integration tests
• PCI DSS 6.5.* (most of it) • Same as Unit Tests

13.2.2 Validate incoming JSON
• Verify that JSON-Schema • Recommended solutions
validation is in place and verified • Review https://json-schema.org
before accepting input. • Consider if necessary
• JSON can contain hostile inputs • Test with malformed JSON
• Relevant standards • JSON with extra information
• OWASP Top 10 (all of it) • Test correct JSON
• OWASP Proactive Controls (all of • End to end integration tests
it) • Test with malformed JSON
• PCI DSS 6.5.* (most of it) • JSON with extra information
• NIST 800-53 AC SI SC SA IA CM • Test correct JSON

13.2.3 CSRF Protection
• Verify that RESTful web services that • Recommended solutions
utilize cookies are protected from • If using cookie-based authentication,
Cross-Site Request Forgery via the use CSRF protection is required
of at least one or more of the • Enforce at the controller (or a filter)
following: triple or double submit • Header based web services are already
cookie pattern, CSRF nonces, or protected
ORIGIN request header checks. • Unauthenticated API don’t need CSRF
protection
• Rationale
• CSRF for cookie based web services is still • Unit Tests
possible • Test without a CSRF token: fail
• Relevant standards • Test with a CSRF token: pass
• OWASP Top 10 (all of it) • End to end integration tests
• OWASP Proactive Controls (all of it) • Test without a CSRF token: fail
• PCI DSS 6.5.* (most of it) • Test with a CSRF token: pass

13.2.4 API Anti-automation
• Verify that REST services have anti- • Recommended solutions
automation controls to protect • API Gateways – technical limits
against excessive calls, especially if • OWASP Automated Threat Handbook
the API is unauthenticated.
• Unit Tests
• Rationale • Attempt to obtain all records
• APIs are designed for B2B and • Should fail
automation
• Abuse is still a problem (scraping, • End to end integration tests
disclosure, etc) • Attempt to sign up, login, lockout, or
obtain all users’ data

13.3.1 SOAP – Schema validation
• Verify that XSD schema validation • Recommended solutions
takes place to ensure a properly • Xerces and other implementations
formed XML document, followed by • Consider if necessary
validation of each input field before
any processing of that data takes • Unit Tests
place. • Test with malformed XML
• XML with extra information
• Rationale • Test correct XML
• Data should be validated before use
• XSD replaces DTD validation • End to end integration tests
• xsd:string == no validation • Test with malformed XML
• XML with extra information
• Relevant standards • Test correct XML

13.3.2 SOAP WS-Security Confidentiality
• Verify that the message payload is • Recommended solutions
signed using WS-Security to ensure • Use TLS
reliable transport between client • Sign messages using WS-Security
and service. • Unit Tests
• Rationale • Not testable
• Solves many RESTful security issues • End to end integration tests
• Relevant standards • Ensure that connections are over TLS
• OWASP Top 10 (all of it) • Test a signed message: pass
• OWASP Proactive Controls (all of it) • Test an unsigned message: fail
13.4.1 GraphQL Expression DoS
• Verify that query whitelisting or a • Recommended solutions
combination of depth limiting and • Go to Ahbay Bhargav’s talk on GraphQL
amount limiting should be used to security
prevent GraphQL or data layer expression • Unit Tests
denial of service (DoS) as a result of
expensive, nested queries. For more • Test various GraphQL expressions
advanced scenarios, query cost analysis • Infinite loop
should be used. • Selects all records
• Performs complex expressions
• Rationale
• Has many of the same attributes as SQL • End to end integration tests
servers, but field / JSON based • Test various GraphQL expressions
• Infinite loop
• Relevant standards • Selects all records
• OWASP Top 10 (all of it) • Performs complex expressions

13.4.2 GraphQL Access Control
• Verify that GraphQL or other data • Recommended solutions
layer authorization logic should be • Implement GraphQL access control
implemented at the business logic on a trusted layer
layer instead of the GraphQL layer. • Unit Tests
• Rationale • Test that GraphQL requires
• Upcoming data access technology authentication and role-based
• Has many of the same attributes as security to use
SQL servers, but field / JSON based • End to end integration tests
• Relevant standards • Try to execute valid GraphQL queries
• OWASP Top 10 (all of it) with authentication: pass
• OWASP Proactive Controls (all of it) • Without authentication: fail
• PCI DSS 6.5.* (most of it) • With appropriate access tokens: pass
• NIST 800-53 AC SI SC SA IA CM • With missing access control: fail

API Security Lab
V14 Configuration
Nearly done!
TM
GLOBAL APPSEC DC
What is Configuration Security
• Common set of mistakes
• Outdated components
• Web Server
• Application Server
• Database Server(s)
• Serverless / Cloud configuration
• File permissions and so on

Some past breaches
• Equifax – 147m records
• RCA – insufficient patching of
outdated software
• Capital One – 100 m records

• Cloud config issue
• CEH Breach – 60k IDs

• Config issue (1st hack)
• Password re-use (2nd hack)

14.2.1 Dependency checks every build
• Verify that all components are up • Recommended solutions
to date, preferably using a • OWASP Dependency Check
dependency checker during build • OWASP Dependency Tracker
or compile time. • BlackDuck, SonarCube
• Outdated software bugs • None
• Vulnerable software shouldn’t be in
production • End to end integration tests
• Bug Gapping • None
• Relevant standards • Build Step
• OWASP Top 10 A9 • Builds should warn if out of date
• OWASP Proactive Controls C2 • Builds must fail if vulnerable
• PCI DSS 6.5.6
• NIST 800-53 SI
14.2.2 Deploy only what’s necessary
• Verify that all unneeded features, • Recommended solutions
documentation, samples, • Automate builds using Ansible, Docker,
configurations are removed, such as etc
sample applications, platform • Find extraneous stuff in documentation
documentation, and default or and builds and remove it in the build
example users. script
• Reduce attack surface • Not applicable
• Harden configuration • End to end integration tests
• OWASP Top 10 A9 • Build tests
• OWASP Proactive Controls C2 • Review finished builds for detritus,
• PCI DSS 6.5.6 change the script
• NIST 800-53 SI • Rinse and repeat until clean

14.2.3 Subresource integrity
• Verify that if application assets, such as • Recommended solutions
JavaScript libraries, CSS stylesheets or • Configure sub-resource integrity for every
web fonts, are hosted externally on a script include and asset
content delivery network (CDN) or • Configure CSP to cover just these CDNs
external provider, Subresource Integrity • Ensure that users cannot force the choice of
(SRI) is used to validate the integrity of older libraries (such as Google API or CF
the asset. CDN)
• Allows use of edge networks / CDNs • Not applicable
• Allows safer use of assets where you can’t • End to end integration tests
see if they are being attacked
• Ensure that sub-resource integrity
• Relevant standards signatures are included
• OWASP Top 10 A9 • Ensure that assets are correctly loaded
• PCI DSS 6.5.6
• NIST 800-53 SI

14.3.1 User friendly error messages
• Verify that web or application server • Recommended solutions
and framework error messages are • Build out custom error messages that are
configured to deliver user actionable, actionable by the end users
customized responses to eliminate • Send detailed exceptions, etc to logs for
any unintended security disclosures. later analysis
• Detailed error messages help attackers • Not applicable
• Users can’t usually make heads or tails of • End to end integration tests
detailed errors • Try to force an error
• Relevant standards • Custom error page: pass
• OWASP Top 10 A9 • Exception page: fail
• PCI DSS 6.5.6
• NIST 800-53 SI

14.3.2 Production means production
• Verify that web or application server • Recommended solutions
and application framework debug • Build debug and production builds
modes are disabled in production to • Debug – has consoles, no minification,
eliminate debug features, developer and debug logging
consoles, and unintended security • Production – no consoles, full
disclosures. minification, no debug logging
• Disable debug mode • Not applicable
• Production builds (even for webpack) • End to end integration tests
• Relevant standards • Attempt to open debug consoles
• OWASP Top 10 A9 • Attempt to force the logging of a debug
• OWASP Proactive Controls C2 canary
• PCI DSS 6.5.6
• NIST 800-53 SI

14.3.3 Remove marketing headers
• Verify that the HTTP headers or any • Recommended solutions
part of the HTTP response do not • Configure the WAF to remove these
expose detailed version information of headers
system components. • Configure the web server to disable these
headers
• Rationale
• Marketing headers help OS vendors, not • Unit Tests
you • Not applicable
• Only Alexa, marketers, and attackers use • End to end integration tests
this information
• Test that marketing headers have been
• Relevant standards removed
• OWASP Top 10 A9
• PCI DSS 6.5.6
• NIST 800-53 SI

14.4.1 Set a safe content type
• Verify that every HTTP response • Recommended solutions
contains a content type header • Use UTF-8
specifying a safe character set (e.g., • Unit Tests
UTF-8, ISO 8859-1).
• Not applicable
• Rationale
• Might be able to convince older
browsers to include XSS from another • Ensure that a suitable character set is
character set used, preferably UTF-8
• OWASP Top 10 A9
• PCI DSS 6.5.6
• NIST 800-53 SI

14.4.2 Set a safe API content type
• Verify that all API responses • Recommended solutions
contain Content-Disposition: • Set an appropriate content
attachment; filename="api.json" disposition header
(or other appropriate filename for • Unit Tests
the content type). • Not applicable
• Prevents the use of API responses for • Test that the application sends an
HTML XSS appropriate content-disposition
• Relevant standards header
• OWASP Top 10 A7
• PCI DSS 6.5.7
• NIST 800-53 SI

14.4.3 Set a Content Security Policy
• Verify that a content security policy • Recommended solutions
(CSPv2) is in place that helps mitigate
impact for XSS attacks like HTML, • Set a minimal content security
DOM, JSON, and JavaScript injection policy header
vulnerabilities.
• If third party sites are not used,
• Rationale include “frame-ancestors”
• CSP prevents most XSS
• CSP makes CSRF harder • Unit Tests
• CSP protects against include attacks
• Not applicable
• PCI DSS 6.5.6 • Test that a CSP header is present
• NIST 800-53 SI

14.4.5 Ensure only TLS
• Verify that HTTP Strict Transport • Recommended solutions
Security headers are included on all • Set a strict transport security header
responses and for all subdomains, • Configure the web server to only redirect
such as Strict-Transport-Security: max- from unencrypted ports
age=15724800; includeSubdomains. • Unit Tests
• Forces browsers to always use TLS • End to end integration tests
• Stops attackers downgrading comms • Test that a strict transport security
• Relevant standards header is set
• OWASP Top 10 A9
• PCI DSS 6.5.6
• NIST 800-53 SI

14.4.6 Limit referer disclosure
• Verify that a suitable "Referrer- • Recommended solutions
Policy" header is included, such as • Set a referrer policy header,
"no-referrer" or "same-origin". preferably no referrer
• Only marketers use this information • Not applicable
• Attackers attack marketers • End to end integration tests
• Attackers know all about you • Test that the Referer-Policy header is
• Relevant standards present and set to the appropriate
value
• OWASP Top 10 A9
• PCI DSS 6.5.6
• NIST 800-53 SI

14.5.2 Don’t trust Origin headers
• Verify that the supplied Origin header • Recommended solutions
is not used for authentication or • Use a strict ACAO header
access control decisions, as the Origin • Unit Tests
header can easily be changed by an
attacker. • Test that the Origin request parameter is
not echoed to the ACAO header
• Origin headers are attacker controlled • Test that the Origin request parameter is
• Reflecting or trusting Origin headers is not echoed to the ACAO header
extremely unwise and will lead to
exploitation
• OWASP Top 10 A9
• PCI DSS 6.5.6
• NIST 800-53 SI

14.5.3 Use known ACAO headers
• Verify that the cross-domain resource • Recommended solutions
sharing (CORS) Access-Control-Allow- • Use a strict ACAO header
Origin header uses a strict white-list of • Unit Tests
trusted domains to match against and
does not support the "null" origin. • Test that the ACAO header is present and
one of the permitted values
• Misconfigured CORS is a popular bug • Test that the ACAO header is present and
bounty finding one of the permitted values
• Can bypass access controls
• OWASP Top 10 A5 A6
• PCI DSS 6.5.6
• NIST 800-53 SI

Demo and Labs
CVEDETAILS.COM
FINDING OUT IF WE’RE USING THE LATEST COMPONENTS
Tournament
Compete against yourself or everyone in the room!
TM
GLOBAL APPSEC DC
Objective – Find all the bugs!
•Join code
• Tournament has exercises in a
bunch of languages and
frameworks
• Points are awarded for fixing
code
• Teaming up is absolutely fine!
• Try to combine skills in multiple
languages and frameworks
• Testing is just as important as
3492 4588
coding

References
TM
GLOBAL APPSEC DC
https://owasp.org

OWASP Application Security Verification
Standard
• Get it here:
• https://www.owasp.org/index.php/Category:OWASP_Application
_Security_Verification_Standard_Project
• Fork it here:
• https://github.com/OWASP/ASVS

OWASP Proactive Controls
• Get it or translate it here:
• https://www.owasp.org/index.php/OWASP_Proactive_Controls

OWASP Cheat Sheets
• Get it here:
• https://cheatsheetseries.owasp.org/
• Fork it here:
• https://github.com/OWASP/CheatSheetSeries

OWASP Top 10 2017
• Get Top 10 2017 here:

• https://github.com/OWASP/Top10
• Fork or translate it here:

• https://github.com/OWASP/Top10
• Top 10 2020 will be released Q3 2020

OWASP Testing Guide v4
• Get it here:
• https://www.owasp.org/index.php/OWASP_Testing_Project

OWASP Dependency Checker
• Get it here:
• https://www.owasp.org/index.php/OWASP_Dependency_Check
• Fork it here:
• https://github.com/jeremylong/DependencyCheck

OWASP Zap
• Get it here:
• https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Projec
t
• Fork it here:
• https://github.com/zaproxy/zaproxy/

Wrapping up
TM
GLOBAL APPSEC DC
Rate this Session
Thank you!
vanderaj@owasp.org
@vanderaj
1 510 697 9315
SCAN THE QR CODE TO

COMPLETE THE SURVEY
Thank You!
TM
GLOBAL APPSEC DC
OWASP, Open Web Application Security Project, Global AppSec and AppSec Days are Trademarks of the OWASP Foundation, Inc.
Copyright notice and license
• Copyright © 2008 – 2019 The

OWASP Foundation.
• This document is released under

the Creative Commons
Attribution ShareAlike 3.0
license. For any reuse or
distribution, you must make
clear to others the license terms
of this work.
OWASP Brand Usage Guidelines
• The Open Web Application Security Project (OWASP) is a
501(c)(3) worldwide not-for-profit charitable organization
focused on improving the security of software.
• Our mission is to make software security visible, so that
individuals and organizations worldwide can make informed
decisions about true software security risks.
• Everyone is free to participate in OWASP and all of our
materials are available under a free and open software
license. You'll find everything about OWASP linked from our
wiki and current information on our OWASP Blog.
• OWASP does not endorse or recommend commercial
products or services, allowing our community to remain
vendor neutral with the collective wisdom of the best minds
in software security worldwide. We ask that the community
look out for inappropriate uses of the OWASP brand including
use of our name, logos, project names and other trademark
issues.
• https://owasp.org

AppSec DC 2019 ASVS 4.0 Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AppSec DC 2019 ASVS 4.0 Final

Uploaded by

Copyright:

Available Formats

Securing Applications with OWASP

Application Security Verification

OWASP GLOBAL APPSEC - DC

• OWASP Board member 2015-2018

• Family, cats, WRC nut

OWASP GLOBAL APPSEC - DC

• What are your biggest

OWASP GLOBAL APPSEC - DC

• V9 Communications Security • V6 Cryptography at rest

• V10 Malicious Code • V7 Logging and Error Handling

OWASP GLOBAL APPSEC - DC

• V14 Configuration • V12 Files and Resources

• Secure Code Warrior Tournament

• References and Wrap Up

OWASP GLOBAL APPSEC - DC

• Each item is a single concept

• Adopted by many governments, large

• More than 1100 “do not do X” CWEs

OWASP GLOBAL APPSEC - DC

• DevSecOps means no more

This Photo by Unknown Author is licensed under CC BY-SA

OWASP GLOBAL APPSEC - DC

• The future is not

OWASP GLOBAL APPSEC - DC

OWASP GLOBAL APPSEC - DC

• Level 1 contains 136 controls

• Far better than the OWASP Top 10

This Photo by Unknown Author is licensed under CC BY-SA

OWASP GLOBAL APPSEC - DC

• Some controls are one-time activities

• Includes secure SDLC and architecture

OWASP GLOBAL APPSEC - DC

OWASP GLOBAL APPSEC - DC

• ASVS contains nearly 300 items • Focus:

OWASP GLOBAL APPSEC - DC

Waterfall (and some Wagile) Today’s agile (and some Wagile)

OWASP GLOBAL APPSEC - DC

• You Are Gonna Need It (YAGNI) Retrospectives User stories

• Developers are engineers

Design for security Peer reviews

TDD - Unit tests

OWASP GLOBAL APPSEC - DC

• Threats • Abuse cases

OWASP GLOBAL APPSEC - DC

• How do we reduce the number of security

OWASP GLOBAL APPSEC - DC

• Aligned with web app risks

• Let’s play the game

• Can download for free

OWASP GLOBAL APPSEC - DC

• Aligned with Microsoft SDL

• Let’s play the game

• Can buy from Microsoft

OWASP GLOBAL APPSEC - DC

• Write unit tests to validate your

• Allows penetration testers to

OWASP GLOBAL APPSEC - DC

• End to end testing is critical

OWASP GLOBAL APPSEC - DC

• Install GitHub Desktop

• You now have a forked copy

OWASP GLOBAL APPSEC - DC

• git remote add upstream