Secure Coding for devs 2022

Open Web Application Security Project (OWASP)

1. Broken Access Control

Happens when devs fail to implement the principle of least privilege. May allow users (like
attackers) to interact with apps in unintended ways like accessing, modifying or deleting data
that actually should’t have been possible. Example can be when attackers can grant themselves
elevated privileges or access to sensitive data (like someone else’s account).
Coding tips:
Deny by default (Tie the CRUD actions to owner and not everyone else). Minimise attack
windows (dec no. of req a user can make in a period of time, expiring tokens).
After coding:
Devs should work with QA team to perform integration tests.

2. Cryptographic Failures
Happens when sensitive data may get leaked. To prevent, identify data that is sensitive
(Personal Identifiable Information, Personal Health Information, Financial Information, Internal
business information) and try to collect as less data as possible (less data to encrypt, the better)
and try to discard data from persistent storage once work is finished.
Compliance Requirements:
Guidance and Standards like NIST and ISO can help get started. Check for Service Level
Agreements (SLAs) when working for others. Some industries like healthcare, finance and govt
have expectations and regulations, be sure to familiar beforehand. Geographical storage and
processing of data also matters due to regional laws (like GDPR or CCPA). Also check the user’s
data since they can be minors since some geographies legally don’t allow processing of this
data.
Coding tips:
Use authenticated encryption (encryption ensures confidentiality since data can only be read
with the decryption key, authenticated encryption ensures confidentiality and integrity since only
certain people can access the data)
Use cryptographically secure protocols (enforce encryption for browsers by forcing HTTPS and
using software libraries like OPEN SSL. To reduce risk of data leakage, disable caching of
sensitive data.
Document your selection of code libraries, encryption standards, padding methods and hashing
functions for the coding language you are using. Do not hardcode keys or passwords into
application code, instead generate cryptographically random keys and store them in memory as
byte arrays.
Remember to hash and salt user passwords.

3. Injection
 Possible when there is improper validation, filtering or sanitisation of data entered by users
(attackers can insert malicious code). End users can be effected by loss of their sensitive data or
by XSS attack affecting other user’s machine. XSS can be Persistent XSS or Reflected XSS.
Persistent XSS is when malicious code is injected into the application database, and when victim
tries to use the app, the server will pull and run the malicious code ( eg: link to malicious website
to steal user cookies being posted as a comment on a web forum).
Reflected XSS starts with a HTTP request to an application including a malicious script which
will return and may successfully compromise a victim’s browser and in turn their machine. (eg:
attacker sends link to malicious script to user which may steal cookies).
Prevention techniques
Perform static, dynamic, and interactive app testing to identify possible issues before
development.
Search for any syntax which makes requests to interpreters in the environment and ensure input
validation is in place.
Check all places where input from an HTTP req could possibly make it’s way into any of these
calls.
Make considerations for special characters and try to escape special character input.
Incorporate limits on results to queries.
Log suspicious queries after deployment and review them consistently to identify attempted
exploits.

4. Insecure Design
Refers to many weaknesses related to 'missing or ineffective control design'.
To ensure secure design
The Secure Software Development Lifecycle (SSDLC) refers to putting an emphasis on security
during development. It creates a balance of security and coding best practices.
Develop use and misuse cases (Misuse cases are things we do not expect to happen).
When testing the app, UT’s and IT’s should reflect the threat we have developed.
Incorporate access controls based on anticipated attacks (eg: locking out and terminating
inactive sessions, limiting number of concurrent sessions, limiting results from queries, etc)
Limit the resource consumption from user which is more complex than a simple Denial of service.
Identify any design changes and document them since they can impact the security
requirements and decisions made previously.
Incorporate plausibility checks (sanity checks) into both the front-end and back-end to quickly
determine if values fall within expected ranges and variables into expected data types.

5. Security Misconfiguration
This can happen when out-of-the-box features are utilised which may overlook some
security problems. Examples: enabling unnecessary accounts/privileges, using default
passwords, error handling messages which provide information to users which can be used to
prepare for an attack).
Vulnerable and outdated software components may compromise security and constantly
reviewing and updating configurations to account for new components to be misconfigured
during the patch management process.
Additional protections:
Consistent configurations across development, QA and production.
Separate credentials for dev, QA and production must be used.
Minimise attack features by limiting features, components, documentation and frameworks to
only what is necessary.
Taking time to change default accounts and passwords.

6. Vulnerable and outdated components

Attackers typically target known vulnerabilities, and unless the matter is addressed it’s only
a matter of time before the vulnerability is exploited. A formal patch management process must
be implemented. Not only that:
Outline a plan to address vulnerabilities identified before patches are available, Identify
mitigations or controls for components that are no longer supported. Log and inventory the
external dependencies of your web app and schedule regular updates.
Finally, remove any functions, modules or other components in an app that are not in use to limit
the attack surface which helps reduce the needs to be maintained.
Ensure any libraries that are referenced are secure and maintained, ideally with digital signatures
for any components.

7. Identification and Authentication Failures

Passwords and session identifiers (SessionID or session token) are the heart of the risk.
Example:
When there are no password policies or checks to ensure complex passwords created by the
user may make accounts with easier passwords easier for attackers to attack.
Displaying session identifiers in the URL which may cause attackers to attempt to access another
user’s session by changing url.
Reusing of identifiers after successful login may lead to attackers to hijack a user’s session
(maybe by using the same computer later).
Responses to login attempt may reveal whether a username is valid which encourages attackers
to try possible usernames to check if user is in the database.
Best Practices
If default credentials are provided to user then user must be forced to change it immediately
after login.
Users must be allowed to enable MFA and checks for weak passwords and enforce strong
password policies.
Limit failed login attempts to stop brute force
Log failures and notify admins to check for possible attacks.
Randomly assign and securely store session identifiers and prevent them from being visible in
URLs.
Use a server-side session manager to generate the identifiers with high entropy and invalidate
them after logout/idle/absolute timeouts.

8. Software and Data Integrity Failures

This relates to not properly confirming the source and authenticity of software updates
which can effect auto-update functionality or CI/CD pipelines which don’t check the incremental
changes made to the software are legitimate. Integrity means data is protected from
unauthorised modification or deletion. Although enabling auto update to software components
are recommended, it is possible that attackers inject malicious code into source code.
Understanding CI/CD
Continuous Integration and continuous delivery is necessary to avoid software and data integrity
failures, we can use software supply chain tools like OWASP dependency check to check
software components. Digital signatures can be used to confirm the authenticity and integrity of
the software.
Impacts to the supply chain
If attackers compromise source code undetected, then any malicious code added can make it’s
way into end user’s systems and attackers could potentially upload their own updates to be run
on all installations.
Protection against failures
Verify any software which your app relies on, preferably using digital signatures.
Research all modules, functions and libraries which are considered secure for the language we
are using.

9. Security logging and Monitoring failures

These failures can impact detection, escalation and response to potential breaches. If
proper logging is not enabled then working with sensitive data is a gamble. We also need to
make sure that the tools used to collect, store and aggregate logs are also secure.
Testing if logging is enough or not can be done by penetration testing.
Necessary logs practices
If there are repeated login attempts seeming like someone is automating an attack or trying to
use brute force, then we need to collect evidence.
We need to consider the details we need to log like dates, times, devices involved and the format
they’re in.
We need to make sure the storage of these logs are secure and cannot be accessed by any
attackers.

10. Server-Side Request Forgery (SSRF)

SSRF involves web apps fetching remote resources without validating user supplied URLs.
Since modern apps use user-supplied URLs to fetch custom webhooks (HTTP req triggered by
an event). If these URL’s are not validated, attackers can launch SSRF attacks to circumvent
firewalls and network access control lists (ACL).
Threats from attacker:
Attackers can target password stores which can be used to expose further sensitive data.
If the network architecture is unsegmented then attackers can port scan internal servers
exposing open and closed ports based on connection results which can used to map out internal
networks.
Many cloud service providers store metadata at 169.254.169.254 and if attackers can access this
data, they can read metadata to gain sensitive information.
SSRF attacks are not only limited to HTTP, they can also be FTP, SMB or even SMTP.
URIs are generally abused on the way they are parsed
Structure of a URI: scheme://user:pass@host:port/path?query=value#fragment
DNS Rebinding
Domain Name System rebinding is an attack which manipulates how domain names are resolved
with the goal being to redirect apps to malicious webpages. The targeted app receives a
command from the attacker to request a domain under the attacker’s control with possible
malicious scripts. If successfully infected the attacker can access internal IP resources which
can be used to launch other attacks putting both the victim application and the network that the
victim is using as well.
Preventing SSRF
On the network layer, we can reduce the impact and opportunities for attackers to get in.
Configure firewalls and segment remote resources access functionality in separate networks.
On the application layer, implement input validation, especially for user-supplied data which will
prevent redirects to malicious URLs and other external resources.
Preventing SSRF using Firewalls
Block non-essential intranet traffic with 'deny-by-default' firewall policies. When in doubt, block
any potentially external traffic at the network layer.
Log and monitor both accepted and blocked network flows. The owner for firewall rules should
use these results to refine rules over time and identify attack attempts.
Create a positive allow list for URLs, ports and destinations. This combined with firewall blocking
rules will reduce opportunities to get in.
Preventing SSRF using Input Validation
Input validation is the best practice for web apps and also helps prevent SSRF attacks.
Frontend considerations
Use network encryption for frontends with high protection needs. If we need to use VPN, then
there should be a dedicated user groups with clearly defined access permissions.
Don’t deploy services with significant security implications on front end systems like OpenID and
OAuth.