Secure coding guidelines

Secure Coding Guidelines
HACK IN THE LOCK HACKATHON – JULY 2020

About me
• user@server:/home/user:$ whoami > Zakaria SMAHI
• user@server:/home/user:$ uname -a > Zakaria SMAHI
Software Engineer <linkedin.com/in/zsmahi>
• user@server:/home/user:$ history | grep ‘experience’ | more >
▪ Software Engineer and Information System Security
Enthusiast.
▪ +6 years experience in software development & software
design
▪ Talks and workshops in different IT events slideshare.net/zsmahi

Summary
• State of Software Market
• How &When do Cyber Attacks occur ?
• CommonWeb Attacks - OWASPTop 10.
• Secure coding Lifestyle.

State of Software Market
HOW SOFTWARE MARKET HAS EVOLVED

Market Revolution
Industrial Software
Client-Server Apps
Web Apps
Mobile Apps
IoT
1 Billion
web sites all around
the globe by
Feb. 2014
102
Billions
downloaded mobile
app by 2013
212
Billions
Connected devices
by 2020
Sources: NetCraft 2014, Gartner

Security threats
92 %
Of Forbes Global 2000
have been victims of an
incident by 2012
An average of
13 flaws
are detected on an
application
3,61 $
Is the cost of each non-
secure line code
> 80%
Of Web Apps are
vulnerable
90%
Of vulnerabilities are in the
App, while 80% of
security budget is gone to
secure the infrastructure
Sources: Ponemon Institute 2013, Cenzic 2013

How & When do Cyber Attacks occur ?
HOW SOFTWARE MARKET HAS EVOLVED

How do Cyber attacks occur ?
• In order to answer this question we should understand first the
Software Development Life-Cycle and Attacks Life-Cycle concepts.
• Software Development Life-Cycle (SDLC) (aka Application
Development Life-Cycle) is the process for planning, creating, testing
and deploying an Information System.
• Attacks Life-Cycle (ALC) is the process by which sophisticated attacks
are conducted.

Software Development Life-Cycle – SDLC
1
PLANNING
2 ANALYSIS
3 DESIGN
4
IMPLEMEN
TATION
5TESTING
&
INTEGRATI
ON
6
MAINTENA
NCE
Each new feature passes through this cycle
1. Planning
2. Analysis & Design
3. Implementation
4. Testing
5. Deployment
6. Maintenance → GoTo 1
a) Fixing Bugs
b) Developing extra-feature
Source:Wikipedia

Attacks Life-Cycle – ALC
1 Reconnaissance
2 Initial
Compromise
3 Command &
Control
4 Lateral
Movement
5Target
attainment
6 Exfiltration,
Corruption &
Disruption
The typical steps involved in a breach are
1. Reconnaissance – InformationGathering
2. Initial compromise: Bypassing perimeter
defenses & gaining access to the internal
system
3. Command & Control: downloading &
installing a trojan.
4. Lateral Movement: seeking to
compromise additional accounts
5. Target attainment: the attacker has
multiple remote entry points and he
understands the IT environment.
6. Exfiltration,Corruption & Disruption:
Enjoy “the coffin dance music“!
Source: HelpNetSecurity

How do Cyber attacks occur ?
• After understanding each Life-cycle, we can say that a vulnerability can
appear because of some problems at one (or more) stage(s) of software life-
cycle:
▪ Planning and Analysis : lack of understanding of the need.
▪ Design: no or bad architecture.
▪ Development: No error catching, No user inputs validation, using vulnerable libraries.
▪ Testing : no tests or not enough tests.
▪ Maintenance: creating new bugs when trying to fix old ones.
• In this presentation we’ll focus essentially on development phase and how
to apply secure coding principles.
• Since > 90 % of attacks are on the web and it’s the era of Cloud we’ll focus
our study on web vulnerabilities & web development, but it’s still applicable
on desktop apps.

Common Web Attacks
OWASP TOP 10

OWASP TOP 10
• The OWASPTop 10 is a standard awareness document for developers
and web application security.
• Using this document is the most effective first step to democratize
the secure software development security within your organization.
• It represents a broad consensus about theTOP 10 most critical
security risks to web applications.
• Globally recognized by developers as the first step towards more
secure coding.

1. Injection: (SQL Injections, NoSQL Injections, LDAP injections & OS
Command Injections):This type of attacks occur when user inputs
are not validated before being sent to an interpreter, which
conducts to its execution as a part of a command or a query, the
impact will be the gathering of sensitive data (ex. User accounts,
ServerVersions,…etc.).
• Ex SQL Injection:The query executed for checking a user is:
• SELECT * FROM UsersWhere username = ‘{UserInput}’
• Possible SQL Injection strings :
• SELECT * FROM Users Where username = ‘’OR ‘1’=‘1’ →The attacker can obtain all users.
• SELECT * FROM Users Where username = ‘zsmahi’; DELETE FROM Users Where username =
‘admin’
OWASP TOP 10 Attacks

• Ex OS Command Injection:This code call the
cat command to show the content of a file.
• It’s executed like this : $ ./CommandCat file.txt
• The output will be : “this is the content of
file.txt”
• But what happen if I pass this parameter :
file.txt; ls
• The interpreted command will be cat file.txt; ls
• The output will be:
• “this is the content of file.txt”
• File.txt; anotherFile.txt;

2. Broken Authentication: Due to the poor implementation of
authentication and session management, an attacker can compromise
passwords and sessions to assume other users’ identities temporarily or
permanently .
• Ex: Access to user profiles without being authenticated.
3. Sensitive Data Exposure: Many web applications do not properly protect
sensitive data, such as Personal Information.Attackers may steal or modify such
weakly protected data to conduct frauds, identity theft, …etc. Sensitive data may
be compromised without extra protection (No Encryption).
• Ex:WhenTLS is not used in all pages, an attacker can monitor network traffic and
obtain all your sent data.
4. XML External Entities (XXE): In some old still used apps, this vulnerability can
occur, in fact an attacker can pass an external entity reference (<!ENTITY /> tag)
within the XML Query that will be parsed by XML parser and getting sensitive
data or even engender a Denial of Service.
• Ex: Send to the XML Parser an external reference with no return (Infinite loop).

5. Broken Access Control : Even with a good session management, an
attacker can access unauthorized functionalities or data and perform non
permitted operations normally for a simple user.
• Ex: Access to admin panel with a normal user credentials..
6. Security Misconfiguration : Even if security misconfiguration is not seen,
but it can help an Attacker in his crime by giving him information about
the server, deployed frameworks (Information Gathering).
• Ex: Non secure Http Headers, enabled debug mode in production,Verbose Error
Messages & Exceptions.
7. Cross Site Scripting (XSS): It occurs whenever an application sends data to
web client without proper validation or escaping (Not encoded). XSS
allows hacker to execute scripts in victim’s browser to redirect him to
malicious web site or hijacking his session. It can be reflected or stored.
• Ex: the Script tag: <script>alert(Document.cookies)</script> to steal users' cookies.

8. Insecure Deserialization : Called also Untrusted Deserialization, when an input
can be modified by user, the result will be an untrusted deserialization
vulnerability, in fact the deserialized string can contain a remote malicious code
that will be executed when converted back to binary format
• Ex: CVE-2017-9805Vulnerability discovered in Apache Struts Framework.
9. Using Components with known vulnerabilities: Frameworks, libraries and any
software module run with the same privileges as the caller app, so when we use a
vulnerable component, we may undermine application defenses and enable
various attacks and impacts.
• Ex: Bootstrap 3.4.1 contains an XSS vulnerability <CVE-2019-8331>.
• Ex: SAP NetWeaverAS JAVA (LM ConfigurationWizard) 7.30 contains a broken
authentication <CVE-2020-6287>.
10. Insufficient Logging & Monitoring: Even if it’s not a real attack but without a good
logging strategy and without monitoring, attackers can maintain persistence and
pivot to more systems. Most breach studies show time to detect a breach is over
200 days, typically detected by external parties rather than internal processes or
monitoring.

0
0,5
1
1,5
2
2,5
3
Exploitability
Prevelance
DetectabilityTechnical Impact
Business Impact ****
Comparison between Attacks
Injection XSS XXE BAC * ILM ** CKV ***
- *BAC : Broken Access Control - ** ILM :Insufficient Logging & Monitoring - *** CKV : using Component with KnownVulnerabilities
- ****The business Impact depends on the organization, its size and its data

Secure Coding Lifestyle
/* LIFE RUNS BETTER ON SECURE CODE */

Secure Coding Lifestyle
• Now, after understanding common vulnerabilities and their impact,
it’s high time to change our bad habits and to adopt a new coding
lifestyle.
• In a world where attacks are inevitable, secure coding becomes a
requirement.
• So what should I do to make my code more secure?

Secure Coding Practices
• InputValidation :
▪ Encode data to a common character set before validating (ex. utf-8).
▪ All data should be validated in a trusted system (server-side) using a
standard tested routine for each type of inbound validation.
▪ Centralized the input validation routines for the application. → for
Single Responsibility principle (SOLID principles) and for more
efficiency on validation.
▪ Validate data: check if received data has the expected type (ex. In C#
useTryCast or Cast withinTry-Catch block), with the expected range
and length to avoid IndexOutOfRange Exceptions, Buffer Overflows.
▪ Handle null bytes (0), and specific strings (../ & .. for path) and their
encoded representation.
• Risks addressed:
Injections XSS Unvalidated redirects
and forwards

• Output Encoding :
▪ All data should be encoded in a trusted system (server-side) using a
standard tested routine for each type of inbound validation.
▪ Modern backend programming languages include different encoding
types (html, css, javascript, url).
▪ Centralized the output encoding routines for the application.
▪ Validate data: Prepare response data before sending them. (check if
it’s really what’s expected → safe serialization).
▪ Handle null bytes (0).
Injections XSS Client-Side
Injection

• Parametrize Queries:
▪ Parameterize the queries by binding the variables.
▪ $stmt = $conn->prepare("INSERT INTO MyGuests (firstname, lastname,
email)VALUES (?, ?, ?)"); // php code
$stmt->bind_param("sss", $firstname, $lastname, $email);
▪ In general way for more security in database :
▪ The application should use the lowest possible level of privilege when
accessing the database.
▪ Connection strings should not be hard coded within the application but
stored in a separate configuration file on a trusted system and they should
be encrypted.
SQL Injections

• Implement Identity and Authentication Controls:
▪ Session identifier creation must always be done on server-side.
▪ Implement secure password storage.
▪ Use strong authentication methods, including multi-factor authentication (sms, e-
mail validation) , biometric authentication mechanism.
▪ Implement a secure password recovery mechanism to help users gain access to their
account if they forget their password.
▪ Logout functionality should fully terminate the associated session or connection and
should be available from all pages protected by authorization.
▪ Establish timeout and inactivity periods for every session.
▪ Deny all access if the application cannot access its security configuration information.
▪ Enforce authorization controls on every request, including those made by server-side
scripts.
▪ Restrict access to protected URLs and Functionalities to only authorized users/roles.
▪ Use re-authentication for sensitive or highly secure features.
▪ Use monitoring and analytics to spot suspicious IP addresses and machine IDs.
Broken Authentication
Broken Access Control

• Protect Data & Information:
▪ Use transport layer security (TLS) to encrypt data in transit.
▪ Don’t reinvent the wheel, most programming languages have their
own implemented crypto-libraries, so use them wisely.
▪ Return only minimum needed data. → Queries like ‘Select *’ should
be avoided as possible.
▪ UseTry-Catch blocks and never return a technical exception.
▪ A well codedTry-Catch block can avoid a DoS.
▪ Technical exception should be logged and return a Business
Exception to users
▪ Never return NullReferenceException but return
SearchedUserNotFoundException.
Sensitive
Data
Exposure
Security
Misconfiguration

• Other coding best practices:
▪ Use only known maintained well documented libraries and keep
them up-to-date.
▪ Use managed code instead of unmanaged code.
▪ Use explicit variable types.
▪ Pay attention to compiler warnings →The warning of today is the
vulnerability of tomorrow.
▪ Avoid complexity in designing your solution → KISS (Keep It Simple,
Stupid).
▪ Use an extensible logging framework to ensure that all log entries
are consistent → Apache Log4j.
▪ Do Unit tests.
All vulnerabilities

• Other coding best practices:
▪ Use proper http code error in your API (200 when OK, 401 when
unauthorized, 403 when forbidden,..etc.).
▪ Use secure captcha (ex.Google recaptcha) in forms.
▪ Integrate Security testing in your CI:You can use OWASP ZAProxy,
SonarQube (via its security rules), Nexus LifeCycle.
▪ Never trust user inputs, always validate inputs and encode outputs.
▪ Always code as if the person who ends up maintaining your code is a
violent psychopath who knows where you live.
▪ Never stop learning, because once you stop learning you start dying.
All vulnerabilities

Further reading
• OWASPTOP 10: https://owasp.org/www-project-top-ten/
• OWASP Secure Coding Practices: https://owasp.org/www-pdf-
archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf
• ANSSI Recommandations : https://www.ssi.gouv.fr/
• 9hours free online training to understand secure coding principles:
https://www.cybrary.it/course/secure-coding/

Secure coding guidelines

More Related Content

What's hot (20)

Similar to Secure coding guidelines (20)

More from Zakaria SMAHI (12)

Recently uploaded (20)

Secure coding guidelines