Assignment: 2

Programming for Security Professionals

Qurat-ul-ain Islam (22066)

Question #1: Describe the latest ten vulnerabilities in coding and

their remediation/Solution with references.

What is an Application Vulnerability?

An application vulnerability is a system flaw or weakness in an application that could
be exploited to compromise the security of the application. Once an attacker has
found a flaw, or application vulnerability, and determined how to access it, the
attacker has the potential to exploit the application vulnerability to facilitate a cyber
crime. These crimes target the confidentiality, integrity, or availability (known as the
“CIA triad”) of resources possessed by an application, its creators, and its users.
Attackers typically rely on specific tools or methods to perform application
vulnerability discovery and compromise. According to Gartner Security, the
application layer currently contains 90% of all vulnerabilities.

What Are Software Vulnerabilities?

Software vulnerabilities are weaknesses or flaws present in your code.
Unfortunately, testing and manual code reviews cannot always find every
vulnerability. Left alone, vulnerabilities can impact the performance and security of
your software. They could even allow untrustworthy agents to exploit or gain access
to your products and data. So, you need to know the top 10 most common
vulnerabilities.

What Causes Software Vulnerabilities?

Software vulnerabilities are often caused by a glitch, flaw, or weakness present in the
software.The most effective way to prevent software vulnerabilities is to use secure
coding standards to enforce security standards.

TOP 10 Most Common Software Vulnerabilities

According to the OWASP Top 10, here are the most common vulnerabilities

1) Injections
Injections are among the oldest and most dangerous attacks to any web application. In
this attack, the attacker simply sends malicious data, in order to make the application
process it and do something it is not supposed to do. Injection flaws are very
prevalent, particularly in legacy code. The core reason being: User-supplied data is
not validated, filtered or sanitized by the application.Injection flaws, such as SQL,
NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter
as part of a command or query.(SQL databases are relational, NoSQL are non-
relational. SQL databases use structured query language and have a predefined
schema. NoSQL databases have dynamic schemas for unstructured data. ... SQL
databases are table based, while NoSQL databases are document, key-value, graph or
wide-column stores.)
Some other potential reasons include:

 Using dynamic queries directly in the interpreter.

 Using non-parameterized calls without implementing context-aware escaping

(auto-escaping in short) directly in the interpreter. Hostile data being used within
object-relational mapping (ORM) search parameters to extract additional,
sensitive records.

 Hostile data being used or concatenated directly, such that the SQL or command
contains both structure and hostile data in dynamic queries, commands, or stored
procedures.

How to prevent injection flaws: The only sure way to prevent Injection attacks
is input validation and parametrized queries including prepared statements. The
application code never utilize the info straightforwardly.

https://deepsource.io/blog/owasp-top-ten-injection/

2) Broken authentication
Broken authentication refers to the vulnerabilities or weaknesses inherent in an online
platform or application that allows hackers to bypass the login security and gain
access to all the privileges owned by the hacked user.  Authentication ensures that
only a verified user can access the information and privileges on the web application.
It gets ‘broken’ when an attacker bypasses the process and impersonates the user on
the application

Impact of Broken Authentication

.Broken authentication targets passwords, keys, session tokens, or other entities
dealing with the user’s identity. The broken authentication and session management
flaws permit attackers to target a specific or group of account holders. If the attacker
is successful, they get full access to the account and can harm the victim in many
ways. The attacker can cause reputational and financial loss. They can act as an
impostor to malign the personal relationships of the victim, too. Selling the
compromised credentials to the other party is another possibility.

How to prevent missing or broken authentication

Using multi-factor authentication can help verify the correct user. Creating strong
passwords with periodic password updates can keep from common password use.

https://relevant.software/blog/web-application-security-vulnerabilities/
https://www.jigsawacademy.com/blogs/cyber-security/broken-authentication/
3) Sensitive Data Exposure
Sensitive data is any information that’s meant to be protected against unauthorized
access. Data exposure happens when data is left unencrypted in a database or server
accessible to anyone. Sensitive data are often exposed when configuration details for
systems and applications are left unsecured online. Sensitive data can include
anything from personally identifiable information (PII), like social insurance
numbers, to banking information, to login credentials. When this data is accessed by
an attacker as a results of a data breach, users are in danger for sensitive data
exposure.

SENSITIVE DATA EXPOSURE EXAMPLES

 Credit card encryption
 SSL is not used for all authenticated pages
 The password database uses unsalted hashes to store everyone’s passwords

How to Prevent Sensitive Data Exposure

 Encrypt data during transport and at rest.
 Minimize data surface area.
 Use the latest encrytion algorithms.
 Disable autocomplete on forms that collect data.
 Disable caching on forms that collect data

https://hdivsecurity.com/owasp-sensitive-data-exposure

4) XML External Entities (XXE).

XML external entity injection, also referred to as XXE attacks, is one amongst the
foremost common security vulnerabilities in web applications, APIs, and
microservices. It allows hackers to handle an application’s processing of XML data.
By performing an XXE Injection, attackers can view files on the application server
filing system, or interact with any backend external systems that the application itself
can access.XXE injection attacks exploit support for XML external entities and are
used against web applications that process XML inputs. Attackers can supply XML
files with specially crafted DOCTYPE definitions to an XML parser with a weak
security configuration to perform path traversal, port scanning, and numerous attacks,
including denial of service, server-side request forgery (SSRF), or even remote code
execution.

How to prevent XXE vulnerabilities

Virtually all XXE vulnerabilities arise because the application's XML parsing library
supports potentially dangerous XML features that the application does not need or
intend to use. The easiest and most effective way to prevent XXE attacks is to disable
those features. Generally, it is sufficient to disable resolution of external entities and
disable support for XInclude. This can usually be done via configuration options or by
programmatically overriding default behavior. Consult the documentation for your
XML parsing library or API for details about how to disable unnecessary capabilities.

5) Broken Access control

Access control enforces policy such that users cannot act outside of their intended
permissions. Failures typically lead to unauthorized information disclosure,
modification or destruction of all data, or performing a business function outside of
the limits of the user. Common access control vulnerabilities include:
 Bypassing access control checks by modifying the URL, internal application
state, or the HTML page, or simply using a custom API attack tool
 Allowing the primary key to be changed to another's users record, permitting
viewing or editing someone else's account.
 Elevation of privilege. Acting as a user without being logged in, or acting as an
admin when logged in as a user.
 Metadata manipulation, such as replaying or tampering with a JSON Web Token
(JWT) access control token or a cookie or hidden field manipulated to elevate
privileges, or abusing JWT invalidation
 CORS misconfiguration allows unauthorized API access.
 Force browsing to authenticated pages as an unauthenticated user or to privileged
pages as a standard user. Accessing API with missing access controls for POST,
PUT and DELETE
.
How to prevent Broken Access Control
 Access control is only effective if enforced in trusted server-side code or server-
less API, where the attacker cannot modify the access control check or metadata.
 Deny access to functionality by default.
 Use Access control lists and role-based authentication mechanisms.
 Do not just hide functions.

BROKEN ACCESS CONTROL EXAMPLES

The application uses unverified data
An attacker simply force browses to target URLs

https://hdivsecurity.com/owasp-broken-access-control

6) Security Misconfiguration
Security Misconfiguration is simply defined as failing to implement all the security
controls for a server or web application, or implementing the security controls, but
doing so with errors.Security misconfigurations arise when security settings are not
defined, implemented, and default values are maintained. Usually, this means the
configuration settings do not comply with the industry security standards (CIS
benchmarks, OWASP Top 10 etc) which are critical to maintaining security and
reduce business risk. Misconfiguration normally happens when a system or database
administrator or developer does not properly configure the security framework of an
application, website, desktop, or server leading to dangerous open pathways for
hackers.

Misconfigurations are often seen as an easy target, as it can be easy to detect on

misconfigured web servers, cloud and applications and then becomes exploitable,
causing significant harm and leading to catastrophic data leakage 

Most common misconfigurations including:

 Unpatched systems
 Default/ out of the box account settings (i.e. usernames and passwords)
 Unencrypted files
 Old and out of date web applications
 Unsecured devices
 Web application and cloud misconfiguration
 Insufficient firewall protection

How to Prevent Security Misconfiguration

The principle of least privilege: Everything off by default.

 Disable administration interfaces.

 Disable debugging.
 Disable use of default accounts/passwords.
 Configure server to prevent unauthorized access, directory listing, etc.
 Consider running scans and doing audits periodically to help detect future
misconfigurations or missing patches.

SECURITY MISCONFIGURATION EXAMPLES

The app server admin console is automatically installed and not removed
Directory listing is not disabled on your server
App server configuration allows stack traces to be returned to users, potentially
exposing underlying flaws.
https://hdivsecurity.com/owasp-security-misconfiguration

7) Cross-site scripting (XSS).

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an
attacker to compromise the interactions that users have with a vulnerable application.
It allows an attacker to circumvent the same origin policy, which is designed to
segregate different websites from each other. Cross-site scripting vulnerabilities
normally allow an attacker to masquerade as a victim user, to carry out any actions
that the user is able to perform, and to access any of the user's data. If the victim user
has privileged access within the application, then the attacker might be able to gain
full control over all of the application's functionality and data.The actual impact of an
XSS attack generally depends on the nature of the application, its functionality and
data, and the status of the compromised user.XSS flaws occur whenever an
application includes untrusted data in a new web page without proper validation or
escaping, or updates an existing web page with user-supplied data using a browser
API that can create HTML or JavaScript. XSS allows attackers to execute scripts in
the victim’s browser which can hijack user sessions, deface web sites, or redirect the
user to malicious sites.

There are three main types of XSS attacks. These are:

 Reflected XSS, where the malicious script comes from the current HTTP request.
 Stored XSS, where the malicious script comes from the website's database.
 DOM-based XSS, where the vulnerability exists in client-side code rather than
server-side code.

https://portswigger.net/web-security/cross-site-scripting

8) Insecure Deserialization.
Insecure Deserialization is a vulnerability which occurs when untrusted data is used to
abuse the logic of an application, inflict a denial of service (DoS) attack, or even
execute arbitrary code upon it being deserialized.Insecure deserialization often leads
to remote code execution. Even if deserialization flaws do not result in remote code
execution, they can be used to perform attacks, including replay attacks, injection
attacks, and privilege escalation attacks.

How can deserialization be insecure?

If the function that is responsible for converting serial data into a structured object
assumes that the data is trusted, an attacker may format the serial data in such a way
that the result of deserialization is malicious. Unfortunately, many standard
deserialization functions in programming languages assume that the data is safe.

How to avoid insecure deserialization?

The most important rule of web security is: never trust user input. This rule also
applies to insecure deserialization vulnerabilities. To avoid them, you should assume
that an attacker may provide malicious user input. Therefore, you must make sure that
the programming language that you use and the deserialization function that you use
is safe. Most languages provide safe deserialization libraries.

Reference: What is Insecure Deserialization? | Acunetix

9) Using components with unknown vulnerablities

Some vulnerable components (e.g., framework libraries) can be identified and
exploited with automated tools, expanding the threat agent pool beyond
targeteVirtually every application has these issues because most development teams
don't focus on ensuring their components/libraries are up to date. In many cases, the
developers don't even know all the components they are using, never mind their
versions.If a vulnerable component is exploited, such an attack can facilitate serious
data loss or server takeover. Applications and APIs using components with known
vulnerabilities may undermine application defenses and enable various attacks and
impactsd attackers to include chaotic actors.

Prevention
Manual updates
One option is not to use components that you didn't write. But that's not very realistic.
Most component projects do not create vulnerability patches for old versions. Instead,
most simply fix the problem in the next version. So upgrading to these new versions is
critical. 
Use Hdiv
 Hdiv vulnerable software detection tools promote a more pragmatic approach,
analysing software dependency both during build time and at runtime, to easily detect
vulnerable bits of software that should be replaced for newer versions. The tools are
designed to cover the whole application lifecycle.

Reference: Components with known vulnerabilities | Hdiv Documentation

(hdivsecurity.com)
Components with Vulnerabilities - Tutorialspoint A9:2017-Using Components with
Known Vulnerabilities | OWASP

10) INSUFFICIENT LOGGING AND MONITORING

According to OWASP, “Exploitation of insufficient logging and monitoring is
the bedrock of nearly every major incident. Attackers rely on the lack of
monitoring and timely response to achieve their goals without being detected.”
Most breach studies show time to detect a breach is over 200 days, typically detected
by external parties rather than internal processes or monitoring.Insufficient logging
and monitoring, coupled with missing or ineffective integration with incident
response, allows attackers to further attack systems, maintain persistence, pivot to
more systems, and tamper, extract, or destroy data

INSUFFICIENT LOGGING AND MONITORING EXAMPLES

Example
An open source project forum software run by a small team was hacked using a flaw
in its software. The attackers managed to wipe out the internal source code repository
containing the next version, and all of the forum contents. Although source could be
recovered, the lack of monitoring, logging or alerting led to a far worse breach. The
forum software project is no longer active as a result of this issue.
Prevent: 
 As per the risk of the data stored or processed by the application: Ensure all
login, access control failures, and server-side input validation failures can be
logged with sufficient user context to identify suspicious or malicious accounts,
and held for sufficient time to allow delayed forensic analysis. 
 Ensure that logs are generated in a format that can be easily consumed by a
centralized log management solutions. 
 Ensure high-value transactions have an audit trail with integrity controls to
prevent tampering or deletion, such as append-only database tables or similar. 
Establish effective monitoring and alerting such that suspicious activities are
detected and responded to in a timely fashion 
 Establish or adopt an incident response and recovery plan, such as NIST 800-61
rev 2 or later. 
 There are commercial and open source application protection frameworks such
as OWASP AppSensor (old wiki), web application firewalls such as ModSecurity
with the OWASP ModSecurity Core Rule Set, and log correlation software with
custom dashboards and alerting.

Reference: A10:2017-Insufficient Logging & Monitoring | OWASP

Question #2: Explain the reasons of weak secure coding with
reference.

Secure Coding
Secure coding is the practice of writing software that's protected from vulnerabilities.
And secure coding is more important today than ever before.
In computer security, a vulnerability is a weakness which can be exploited by a threat
actor, such as an attacker, to cross privilege boundaries (i.e. perform unauthorized
actions) within a computer system. To exploit a vulnerability, an attacker must have at
least one applicable tool or technique that can connect to a system weakness. In this
frame, vulnerabilities are also known as the attack surface.

A security risk is often incorrectly classified as a vulnerability. The use of

vulnerability with the same meaning of risk can lead to confusion. The risk is the
potential of a significant impact resulting from the exploit of a vulnerability. Then
there are vulnerabilities without risk: for example when the affected asset has no
value. A vulnerability with one or more known instances of working and fully
implemented attacks is classified as an exploitable vulnerability—a vulnerability for
which an exploit exists. The window of vulnerability is the time from when the
security hole was introduced or manifested in deployed software, to when access was
removed, a security fix was available/deployed, or the attacker was disabled—
see zero-day attack.

Causes of weak secure coding?

Exploits are the means through which a vulnerability can be leveraged for malicious
activity by hackers; these include pieces of software, sequences of commands, or even
open-source exploit kits.
Vulnerabilities are exploit because due to ignorance of the secure coding principle.
Following are some most active causing of weak secure coding.

 Complexity: Large, complex systems increase the probability of flaws and

unintended access points
 Familiarity: Using common, well-known code, software, operating systems,
and/or hardware increases the probability an attacker has or can find the
knowledge and tools to exploit the flaw.
 Connectivity: More physical connections, privileges, ports, protocols, and
services and time each of those are accessible increase vulnerability
 Password management flaws: The computer user uses weak passwords that could
be discovered by brute force. The computer user stores the password on the
computer where a program can access it. Users re-use passwords between many
programs and websites.
 Fundamental operating system design flaws: The operating system designer
chooses to enforce suboptimal policies on user/program management. For
example, operating systems with policies such as default permit grant every
program and every user full access to the entire computer. This operating system
flaw allows viruses and malware to execute commands on behalf of the
administrator
 Internet Website Browsing: Some internet websites may contain
harmful Spyware or Adware that can be installed automatically on the computer
systems. After visiting those websites, the computer systems become infected and
personal information will be collected and passed on to third party individuals.
 Software bugs: The programmer leaves an exploitable bug in a software program.
The software bug may allow an attacker to misuse an application.
 Unchecked user input: The program assumes that all user input is safe. Programs
that do not check user input can allow unintended direct execution of commands
or SQL statements (known as Buffer overflows, SQL injection or other non-
validated inputs).
 Not learning from past mistakes for example most vulnerabilities discovered
in IPv4 protocol software were discovered in the new IPv6 implementations

Bonus Secure Coding Practices

1.Define security requirements. Identify and document security requirements early
in the development life cycle and make sure that subsequent development artifacts are
evaluated for compliance with those requirements. When security requirements are
not defined, the security of the resulting system cannot be effectively evaluated.

2.Model threats. Use threat modeling to anticipate the threats to which the software
will be subjected. Threat modeling involves identifying key assets, decomposing the
application, identifying and categorizing the threats to each asset or component, rating
the threats based on a risk ranking, and then developing threat mitigation strategies
that are implemented in designs, code, and test cases [Swiderski 04].

https://www.perforce.com/blog/sca/what-secure-coding
https://en.wikipedia.org/wiki/Vulnerability_(computing)