Secure coding presentation Oct 3 2020

Secure Coding
What you need to know as a developer
by Moataz Kamel
Oct 3, 2020

Introduction
● 20 years in the software industry
● 14 years delivering security software in the cloud
● Expertise in Email & Web Security cloud
gateways, SDLC, and Scaled Agile/DevOps
● BASc and MASc in Computer Engineering
● Started as a developer, then architect, then
Director then Sr. Director of Development

Motivation: Why application security?

https://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/
Top Attacker motivations:
● Financial
● Reputation
● Hacktivism

Growth of Software Vulnerabilities...
“Reacting to vulnerabilities in
existing systems is not
working…”
We need to “ eliminate
vulnerabilities resulting from
coding errors before they are
deployed.” - Robert C. Seacord
(CERT)
CVE = Common Vulnerabilities
and Exposures
https://blog.rapid7.com/2018/04/30/cve-100k-by-the-numbers/
http://www.open-std.org/JTC1/SC22/WG23/docs/ISO-IECJTC1-SC22-WG23_N0023-Secure-Coding-Standards.pdf

What is Secure Coding?
Secure coding is the practice of developing
computer software in a way that guards against
the accidental introduction of security
vulnerabilities.
Viega, John; Gary McGraw (2001). Building Secure Software: How to Avoid Security
Problems the Right Way. MAddison-Wesley Professional. p. 528. ISBN
978-0201721522.

A Side Note...
Traditionally,
Secure Coding ⇒ Application Security (i.e. Javascript, Python, PHP etc)
Application Security ⍯ Network Security (i.e .Firewalls, VLANs, WAF, etc)
However,
DevOps ⇒ Infrastructure as Code
Therefore,
Secure Coding ⇒ Application Security && Infrastructure Security

Understand the Attack Surface
Code you write
+ Libraries, Frameworks,
+ Communication Paths in/out
+ Code that protects paths
+ Data used in the application
+ Code that protects the data
+ <Infrastructure it all runs on>
https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html

Introducing OWASP
● A volunteer organization of people dedicated to spreading
the word about secure coding and application security
● The OWASP website owasp.org is one of the largest collections of application
security knowledge that has been compiled and is freely available.
● There are many (194) OWASP projects that are free and open source that
you can download to test or improve the security posture of your software
● A great place to start is with the Quick Developers Guide and the Secure
Coding Practices Quick Reference Guide
Open Web Application
Security Project

OWASP First Steps
Security Project
Appsec Tutorial

OWASP Top 10 Web App Sec Risks
1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting
8. Insecure Deserialization
9. Using Components with
Known Vulnerabilities
10. Insufficient Logging &
Monitoringhttps://owasp.org/www-project-top-ten/
The OWASP Top 10 is a standard awareness document for developers
and web application security. It represents a broad consensus about the
most critical security risks to web applications. (Current Version 2017)
Security Project

A1: Injection
Injection ﬂaws, such as SQL, NoSQL, OS, and LDAP injection, occur when
untrusted data is sent to an interpreter as part of a command or query. The
attacker’s hostile data can trick the interpreter into executing unintended
commands or accessing data without proper authorization.
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A1-Injection
Open Web
Application
Security Project

Injection: Example Attack Scenarios
Scenario #1:
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'";
What happens when the attacker modiﬁes the ‘id’ parameter value in their browser to send: ‘ or ‘1’=’1.
For example:
http://example.com/app/accountView?id=' or '1'='1
This changes the meaning of the query to return all the records from the accounts table.
SELECT * FROM accounts WHERE custID='' or '1'='1'
More dangerous attacks could modify or delete data, or even invoke stored procedures.
https://www.w3schools.com/sql/sql_injection.asp

Injection: Example Attack Scenarios
Scenario #2:
txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;
Suppose the following user input
User id: 105; DROP TABLE Suppliers
This changes the meaning of the query to return all the records from the accounts table.
SELECT * FROM Users WHERE UserId = 105; DROP TABLE Suppliers;
https://www.w3schools.com/sql/sql_injection.asp

Injection: How to Prevent?
Failure to properly validate input leads to almost all of the major application
vulnerabilities!
Defense Options (SQL injection)
1. Use prepared statements with parameterized queries
2. Use stored procedures
3. Whitelist input validation (i.e. compare against a list of valid inputs)
4. Escape all user-supplied inputs (i.e. escape any special characters)
https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html
txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = @0";
db.Execute(txtSQL,txtUserId);

A2: Broken Authentication
Broken authentication refers to weaknesses
in two areas: session management and
credential management. Both are
classified as broken authentication because
attackers can use either avenue to
masquerade as a user: hijacked session IDs
or stolen login credentials.
In recent years, broken authentication
attacks have accounted for many of the
worst data breaches.
https://auth0.com/blog/what-is-broken-authentication/
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication
Open Web
Application
Security Project

Authentication: Example Attack Scenarios
Scenario #1: Credential stuﬃng, the use of lists of known passwords, is a common attack. If an application
does not implement automated threat or credential stuﬃng protections, the application can be used as a
password oracle to determine if the credentials are valid.
https://auth0.com/blog/what-is-credential-stuffing/

Authentication: Example Attack Scenarios
Scenario #2: Session Hijacking can occur if application session timeouts are not set properly and sessions
are not encrypted. If an attacker snoops on a public wiﬁ network, they could steal the session information and
use it to browse as that user.

Authentication: Best Practices
● Use unique UserIds that are hard to guess
● Implement password strength controls
● Implement secure password recovery
● Store passwords securely
● Compare password hashes with safe
functions
● Transmit passwords only over TLS or
other strong transport
● Require re-authentication for sensitive
features
● Consider strong transaction authentication
● Protect against automated attacks
using MFA and/or account lockout
https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
OAuth 2.0 and OpenID Connect (in plain English), https://auth0.com/blog/what-is-broken-authentication/
Session Management
● Control session Length (timeout)
● Rotate and invalidate session ids
● Don’t put session ids in URLs (use session
cookies or JWTs)
● Understand your build-in session
management framework and keep it up to
date (e.g. J2EE, ASP.NET, PHP, etc)
● Always use TLS for the entire web session

A3: Sensitive Data Exposure
Sensitive data like passwords, credit card numbers,
health records, personal information require extra
protection.
Rather than directly attacking crypto, attackers can
steal data from web service applications in a
numbers of ways if that data is not encrypted and if
keys are not stored and handled in a safe way.
Open Web
Application
Security Project
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A3-Sensitive_Data_Exposure

A3: Sensitive Data Exposure:
Example Attack Scenarios
Scenario #1: Using a technique known as “Google Hacking”, an attacker searches for sites with txt, log, or
cfg ﬁles with admin_password exposed in plain text
The attacker then uses the admin password to gain access to resources on the site.

Scenario #2: An application encrypts credit card numbers in a database using automatic database
encryption. However, this data is automatically decrypted when retrieved, allowing a SQL injection ﬂaw to
retrieve credit card numbers in clear text.
Encrypted at rest
SELECT User,CreditCardNum
FROM transactions WHERE
user=1199 or 1=1;
All users, credit cards
decrypted
All users, credit cards
decrypted

Best Practices
● Classify sensitive data; don’t store if not needed, discard as soon as possible
● Encrypt data at rest, never store in plaintext
● Use strong, up-to-date encryption algorithms (AES 256). Consider open,
peer-reviewed libraries like Google/Tink
● Manage encryption keys securely (don’t store secrets in code, config files or
env variables, use key stores or secret vaults like KeyWhiz, Hashicorp Vault,
or Amazon KMS.
● Encrypt data in transit with secure protocols like TLS and use perfect forward
secrecy (PFS) and HTTP Strict Transport Security (HSTS).
https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere

A4: XML External Entities (XXE)
An XML External Entity attack is a type of attack
against an application that parses XML input. This
attack occurs when XML input containing a
reference to an external entity is processed by a
weakly configured XML parser.
This attack may lead to the disclosure of confidential
data, denial of service, server side request forgery,
port scanning from the perspective of the machine
where the parser is located, and other system
impacts
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A4-XML_External_Entities_(XXE)
XML
Open Web
Application
Security Project

A4: XML External Entities (XXE):
Scenario #1: An attacker discovers a gaming website that allows users to upload game conﬁgurations in
XML format.The attacker uploads the following xml to the server:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
This results in the server displaying the contents of the passwd ﬁle which the attacker then users to take
over the web server.

Scenario #2: An attacker discovers a 3d printing website that allows users to upload CAD drawings in XML
format.The attacker uploads the following xml to the server:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "http://internal.vulnerable-website.com/" >]>
<foo>&xxe;</foo>
The resulting call is called Server-Side Request Forgery (SSRF) where the server hosting the website makes
a call to the named website in the external entity tag. This type of request forgery can be used to gain
access to privileged information on the private network of the host or to .
https://portswigger.net/web-security/xxe (Exploiting XXE to perform SSRF attacks)

Best Practices
● Use less complex data formats like JSON if appropriate
● Patch or upgrade all XML processors and libraries
● Disable XML external entity and DTD processing in all XML parsers
● Verify that XML file upload functionality validates incoming XML
https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing

A5: Broken Access Control
Access control enforces policies such that users
cannot act outside their intended permissions.
Failures typically lead to unauthorized information
disclosure, modification, or destruction of data, or
performing business functions outside of the
limits of the user (e.g. payment authorization,
granting permissions)
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control
XML
Open Web
Application
Security Project

Scenario #1: An attacker observes the following request made by the application when loading their banking
dashboard.
https://mybankingapp.test/cgi-bin/hpe.py?accountId=4462
The server code is as follows:
pstmt.setString(1, request.getParameter("accountId"));
ResultSet results = pstmt.executeQuery( );
The attacker modiﬁes the request to use the bank account number of another user by changing the accountId
parameter from 4462 to 4463 and receives the account details of another user.
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control
https://www.packetlabs.net/broken-access-control/
XML

Scenario #2: An attacker reviews the html from a popular banking website and ﬁnds this comment:

<div id=”accountBalance”>
The attacker crafts a request based on this information to search the customer database:
https://mybankingapp.test/cgi-bin/customer_search.py?limit=5
The application responds with a list of 100 customers from the applications database.
https://www.packetlabs.net/broken-access-control/
XML

A5: Broken Access Control:
Best Practices
● Access control must be enforced in server side checks
● With the exception of public resources, Deny access by default
● Implement access control once and reuse through the application (linked to
authentication & session management)
● Disable web server directory listing
● Log access control failures and alert admins when appropriate
● Rate limit API and controller to protect against automated attacks
● Include functional access control in unit and integration testing
https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html
XML

Security Tools
Static Application Security Testing
(SAST):
● Analyzes source code to find
security vulnerabilities
● Can be run as part of the build
Dynamic Application Security Testing
(DAST):
● Analyzes running application to
find security vulnerabilities
● Can find security vulns like XSS,
insecure server config, etc

In Conclusion
Keep Learning! (check out the links in the references)
Experiment with OWASP tools!
Let security awareness be your superpower!
Stay Safe and Stay Secure!

References
● OWASP Top Ten Application Security Risks
● OWASP Secure Coding Practices Quick Reference Guide
● OWASP Developer Quick Start Guide
● CERT Security and Secure Coding Standards (for C and C++)
● 2019 CWE (Common Weakness Enumeration) Top 25 Software Errors
● CIS (Center for Internet Security) Top 20 Controls
● UC Berkley Secure Coding Practice Guidelines
● Common Vulnerabilities and Exposures
● What Is the NIST Cybersecurity Framework
● SAST Tutorial: Everything you Need to Know
● OWASP Security Knowledge Framework
● https://www.horangi.com/blog/real-life-examples-of-web-vulnerabilities

Security Practices
1.Validate Input
2.Compiler warnings
3. Design for security
6. Least Privilege
7. Defense In Depth
8. Sanitize sent data
4. KIS
5. Default
Deny
9. QA
https://wiki.sei.cmu.edu/confluence/display/seccode/Top%2B10%2BSecure%2BCoding%2BPractices
https://www.slideshare.net/websecurify/secure-coding
10. Coding
Standard

Secure coding presentation Oct 3 2020

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Secure coding presentation Oct 3 2020

Ähnlich wie Secure coding presentation Oct 3 2020 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Secure coding presentation Oct 3 2020