Software is a set of instructions that tells a device what to do.

Software is a collection of programs, data, and instructions that tell a computer or

other electronic device how to perform specific tasks or operations.

Software development vulnerabilities are flaws or weaknesses in software code that

can be exploited by attackers, potentially leading to security breaches, data leaks, and
other malicious activities.

These vulnerabilities often arise from coding errors, design oversights, or the use of
outdated or insecure components
 Causes
Coding Errors: Poor coding practices, such as using insecure functions or failing to
validate user input, can create vulnerabilities.

Design Flaws: Inadequate security considerations during the design phase can lead to
vulnerabilities that are difficult to address later.

Outdated Components: Using outdated or unsupported software components can

introduce known vulnerabilities.

Misconfiguration: Incorrect configuration of software or systems can expose them to

vulnerabilities.
 Consequences

Data Breaches: Attackers can exploit vulnerabilities to steal sensitive data, such
as personal information, financial details, or intellectual property.

System Compromise: Vulnerabilities can allow attackers to gain unauthorized

access to systems, install malware, or disrupt operations.

Financial Loss: Data breaches and system compromises can lead to significant
financial losses for organizations.

Reputational Damage: Security incidents can damage an organization's

reputation and erode customer trust.
Main Software Development Vulnerabilities
 Buffer Overflow Vulnerabilities
A buffer overflow (or buffer overrun) happens when an application doesn't properly manage
the amount of data it can accept, leading to excessive data being written into memory beyond
the allocated buffer.

When developing software, it's essential to specify the amount of data the application
expects to receive and allocate the appropriate memory to store it. This is called bounds
checking.

Without proper bounds checking, an application might allocate space for 50 characters, but if
1,000 characters are input, the extra 950 characters will overwrite nearby memory. This
memory could contain data from other applications or even critical parts of the operating
system.

This overflow can open the door for attackers to exploit the vulnerability—either to
manipulate other applications or to execute arbitrary commands, potentially compromising
the entire system.
 Preventing Buffer Overflow Attacks

Bounds Checking: Always ensure that input data is validated to fit within the allocated buffer
size. This is the primary defense against buffer overflow attacks.

Language Safety: Some modern programming languages, such as Java and C#, automatically
perform bounds checking, minimizing the risk of buffer overflows.

However, languages like C and C++ require developers to manually handle this task, leaving
room for errors that can lead to vulnerabilities.

In short, careful memory management, especially bounds checking, is key to preventing buffer
overflow vulnerabilities.

Taking these precautions ensures that malicious actors can't exploit overflow conditions to
compromise system security.
 Race Conditions
A race condition occurs when multiple processes or threads share access to a resource, and the system's correct
behavior depends on the order or timing of operations. If not properly synchronized, this can lead to errors.

Example:
Imagine making a $20 withdrawal from your bank account. The process goes like this:
Check balance ($100).
Withdraw funds ($20).
Update balance ($80).

If another user tries to withdraw $30 at the same time:

Both users check the balance ($100).
Both withdraw funds ($20 and $30).
The final balance ends up as $70, not the correct $50.

Because access to the shared resource (the bank account) is not synchronized, this race condition results in an
incorrect balance.
 Challenges
Hard to Detect: Race conditions are difficult to reproduce because they depend on
timing and can be intermittent.

Unpredictable Results: The outcome varies each time, making them challenging to fix.

Prevention

Synchronization: Use locks or semaphores to control access to shared resources.

Atomic Operations: Ensure operations are indivisible, so no interruptions occur.

Avoid Timing Dependencies: Properly manage resource access to avoid relying on

precise timing.
 Input validation Attacks
If we don’t properly validate input in our applications, we may open ourselves up to
various security vulnerabilities, including format string attacks.

A format string attack exploits the format specifiers (such as %f, %n, %p) used in certain
programming languages like C and C++.

These specifiers are typically used in functions like printf to format data output to the
screen, but if input is not carefully validated, they can be manipulated by an attacker to
access or modify a program’s internal memory.

For instance, the %n specifier can be used to write an integer to a specific memory
location.
If an attacker includes %n in their input, they could potentially write arbitrary values to
memory locations that should not be accessible.

This could cause the application to crash or, worse, allow the attacker to execute
commands on the operating system, potentially compromising the system.
 Prevention
This type of vulnerability is primarily related to input validation.

By properly filtering user input, we can block malicious characters or format specifiers,
preventing attacks.

For example:

Sanitize Input: Ensure that user input doesn’t contain characters like %n that could
be interpreted as format specifiers.

Error Handling: Implement error handling to catch unexpected input or malformed

format strings before they can cause issues.
 Authentication Attacks
When designing authentication mechanisms for our applications, it's crucial to use strong, secure
methods to protect against attacks.

By ensuring robust authentication practices, we can significantly reduce the likelihood of unauthorized
access.

Key Factors for Strong Authentication:

Strong Passwords

1. Enforcing the use of strong passwords is one of the most effective defenses. Simple passwords
(e.g., "hellobob") can be cracked quickly, even by modest machines. For example, an 8-character
password made up of lowercase letters can be cracked in seconds.

2. On the other hand, an 8-character password with mixed case letters, numbers, and symbols (e.g.,
"H3lloBob!") would take over two years to crack, even with powerful machines.
Avoid Hard-Coded Passwords:
Never use hard-coded passwords (built-in passwords that can't be changed). These are easily found
and exploited by attackers.

Avoid Client-Side Authentication:

Performing authentication on the client side is risky because it exposes sensitive information to
attackers. A classic example of this vulnerability is the 2010 incident involving hardware-encrypted
flash drives from SanDisk, Kingston, and Verbatim.
These devices used software running on the user's computer to validate the decryption password,
which then sent a fixed unlock code to the device. Attackers were able to bypass this by sending the
same unlock code without needing the actual password.

Best Practices
Use Strong Password Policies: Enforce passwords with a combination of uppercase and lowercase
letters, numbers, and symbols.
Server-Side Authentication: Always handle authentication and sensitive actions on the server side,
keeping the logic and credentials away from the client.
Regularly Update Authentication Mechanisms: Regularly review and update authentication mechanisms
to address new vulnerabilities and stay ahead of attackers.
 Authorization Attacks
Placing authorization mechanisms on the client side is a security risk, as attackers can
easily manipulate client-side logic. Always perform authorization on the server side or
secure hardware.

Key Principles
Principle of Least Privilege: Give users only the minimum permissions they need to
reduce attack opportunities.
Re-check Authorization: Continuously verify that users have permission for sensitive
actions, every time they attempt them.
Control Restricted Access: Prevent users from proceeding if they access restricted areas,
whether by accident or design.
Best Practices:
Use server-side authorization.
Apply least privilege to users and internal processes.
Continuously re-validate user permissions.
 Cryptographic Attacks
Improperly implemented cryptographic controls can lead to severe security vulnerabilities.
Cryptography is easy to get wrong, and poor implementation can create a false sense of
security.
Common Pitfalls
Homegrown Cryptographic Schemes:
Avoid creating custom cryptographic algorithms. Established algorithms like AES
(Advanced Encryption Standard) and RSA have been rigorously tested and are widely
trusted due to their proven strength and security.
False Sense of Security:
While cryptography is essential for securing data, it must be implemented correctly.
Relying on weak or untested encryption can leave your system vulnerable.
Best Practices:
Use Well-Established Algorithms: Stick to widely recognized and tested encryption
algorithms like AES and RSA.
Avoid Custom Cryptography: Use industry-standard, vetted libraries and tools for
encryption.
 Web Security
With the growing use of web pages and applications, careful design and development are
crucial to protect against attacks.

Attackers employ various techniques to compromise systems, steal sensitive information,

and manipulate users into unintended actions.

These attacks generally fall into two categories:

Client-Side Attacks: Targeting the user’s browser or device.

Server-Side Attacks: Targeting the server where the application is hosted.

 Client-Side Attacks

Client-side attacks exploit weaknesses in the software running on user devices or rely on
social engineering to deceive users into participating in the attack.

While there are many types of client-side attacks, we'll focus on those that specifically use
the Web as an attack vector.
Cross-site scripting (XSS) is an attack carried out by placing code in the form of a
scripting language into a Web page, or other media, that is interpreted by a client browser,
including Adobe Flash animation and some types of video files.

When another person views the Web page or media, he or she executes the code
automatically, and the attack is carried out.

A good example of such an attack might be for the attacker to leave a comment containing
the attack script in the comments section of an entry on a blog.

Every person reading the command in her browser would execute the attack
 Cross-Site Request Forgery (XSRF)
XSRF is an attack where an attacker tricks a user into performing unintended actions on a
site where they’re already authenticated, such as transferring money or adding items to a
shopping cart.

Example:
If you’re logged into MySpiffyBank.com and visit a malicious site
(BadGuyAttackSite.com), the attacker could silently perform actions like transferring
money from your bank account without your knowledge.

Prevention:
Use Anti-CSRF Tokens: Include unique tokens for each request.
SameSite Cookies: Use the SameSite attribute to prevent cross-site cookie sending.
Check Referer/Origin: Validate the source of requests.
User Action Confirmation: Require extra confirmation for sensitive actions.
 Clickjacking
Clickjacking is an attack where an attacker tricks a user into clicking on
something they didn’t intend to, by overlaying a malicious element on a webpage.
Example:
An attacker might hide a "Buy Now" button behind a "More Information" button.
When the user clicks on the "More Information" button, they unintentionally click
the hidden "Buy Now" button, completing a purchase without their knowledge.

Prevention
Use X-Frame-Options: Prevent your site from being embedded in iframes.
Content Security Policy (CSP): Use a CSP to restrict content and prevent
clickjacking.
Frame Busting Scripts: Use JavaScript to prevent your site from being loaded in a
frame.
 Protection Against Client-Side Attacks

Most modern browsers (like Internet Explorer, Firefox, Safari, and Chrome) now
automatically block many common attacks, including XSS, XSRF, and Clickjacking.

However, the threat landscape is constantly evolving, and new attacks often build on old
techniques.

Additionally, many vulnerable clients still run outdated, unpatched software, making them
susceptible to older attacks.

To stay protected
Keep Browsers Updated: Ensure your browser is up-to-date with the latest security
patches.
Use Additional Tools: Tools like NoScript (available for Firefox) block most scripts by
default and allow only trusted ones, providing an added layer of defense.
 Server-Side Attacks

Server-side web transactions can face many vulnerabilities.

These issues depend on the OS, web server software, software versions, scripting
languages, and more.

Despite the variety, common security problems often arise across different systems
due to shared risk factors.
 Lack of Input Validation

Websites often let users type information: names, passwords, or messages.

But if the website doesn't check the input properly, hackers can type in something tricky that confuses the
website.
Why Is This Dangerous?
Some websites connect to a database to store or find information.
A hacker can enter strange or harmful text that tells the database to do something it shouldn’t like show
secret data or allow access without a password.
This kind of trick is called an SQL Injection attack.
What Can Happen?
Hackers might see private data (like usernames or passwords).
They might change or delete important info.
They could even take control of the website.

How Can We Prevent It?

Check user input — make sure it’s what we expect (like only letters or numbers).
Block strange symbols that attackers often use (like %, /, ‘, and ;).
Use safe methods when sending data to the database (developers can use built-in tools for this).
 Improper or Inadequate Permissions

Web applications need to protect certain files and folders. If they don’t, it can create big security
risks.

What’s the Problem?

Some files, like configuration files, contain important secrets (like usernames and passwords for
the database).
If these files or folders are not protected properly, anyone can access them — including hackers.
Hackers can then use those secrets to get into the database and steal or change sensitive
information.

What Can Happen If Permissions Are Weak?

Hackers might:
Read secret files
Change your web app
Add harmful files
Delete everything
Why This Happens

Folders and files are left open to the public by mistake

Developers forget to restrict access to sensitive parts of the site
Default settings are not changed to secure ones

How to Prevent It

Only allow access to safe, public files

Keep configuration files private and protected
Regularly check folder and file permissions
Secure all web apps, especially if open to the Internet
 Extraneous Files

When setting up a website, developers often leave behind extra files that aren’t needed for the site
to work.

What Are Extraneous Files?

Backup copies of web pages
Source code archives
Notes or text files
Files with passwords or setup info

Why Are These Dangerous?

If these files are left on the web server, anyone can find and read them
Hackers can use this info to:
Learn how the site works
Steal credentials
Find weak points to attack
How to Prevent This

Before launching a website, remove all unnecessary files

Don’t leave backups or notes on the server

Do regular security checks to make sure nothing extra is exposed

Keep sensitive files in secure, private locations

 DATABASE SECURITY

As we discussed when we went over Web security issues, the vast majority of Web sites and applications in
use today make use of databases in order to store the information they display and process.

In some cases, such applications may hold very sensitive data, such as tax returns, medical data, or legal
records; or they may contain only the contents of a discussion forum on knit ting.

In either case, the data such applications hold is important to the owners of the application and they would
be inconvenienced, at the very least, if it were damaged or manipulated in an unauthorized manner.
Unauthenticated Flaws in Network Protocols

Cause: This occurs when a network protocol does not properly require authentication for
communication. Attackers can exploit this lack of authentication to access the database without
needing a valid username or password.

Example: A web application might use an outdated protocol for communication, allowing anyone
to connect to the database server and access its data without needing to authenticate.

Prevention:
Use secure protocols like SSL/TLS to encrypt the data transmitted between the client and
server.
Implement strong authentication for all network protocols, ensuring that users cannot bypass
authentication mechanisms.
Regularly update network protocols to close any security gaps
Authenticated Flaws in Network Protocols

Cause: Even when authentication is required, flaws in how authentication is handled could
allow attackers to bypass it. For example, attackers may exploit a session fixation or token
theft vulnerability to impersonate authenticated users.

Example: An attacker gains access to the database by intercepting authentication tokens or

using a stolen session cookie, thus bypassing the authentication process.

Prevention:
Implement secure session management using time-sensitive tokens.

Use multi-factor authentication (MFA) to make it harder for attackers to gain unauthorized
access.

Employ session encryption to protect session cookies and tokens from being intercepted.

Regularly rotate authentication credentials and enforce strong password policies.

Flaws in Authentication Protocols

Cause: Authentication mechanisms, such as password hashing algorithms or multi-factor

authentication, may have flaws that allow attackers to bypass or exploit them to gain access to
the database.

Example: A web application uses an outdated or weak password hashing algorithm, such as
MD5, which an attacker can easily crack using brute-force attacks.

Prevention:
Use modern hashing algorithms like bcrypt or argon2 for securely storing passwords.
Implement rate-limiting for login attempts to prevent brute-force attacks.
Ensure that multi-factor authentication is used wherever possible, especially for access to
sensitive data or admin areas.
Regularly audit and improve authentication systems to ensure they remain secure.
 Unauthenticated Access to Functionality

Cause: When a web application allows users to access functionality or data that should be restricted
based on authentication or user roles, it can lead to unauthenticated access.

Example: A public API exposes an endpoint that should only be available to logged-in users but is open to
the public.

An attacker can use this to make requests to the database and access sensitive data.

Prevention:

Enforce strict access control and use role-based access control (RBAC) to ensure that users only
have access to the functionalities they are authorized for.

Validate user credentials and permissions before allowing access to sensitive endpoints.

Implement API security practices such as API keys or OAuth for authentication and authorization.
 Arbitrary Code Execution in Intrinsic SQL Elements

Cause: Intrinsic SQL elements, such as stored procedures or triggers, may be

vulnerable to arbitrary code execution if an attacker can inject malicious SQL code that
the database will execute.

Example: An attacker exploits a SQL injection vulnerability to insert malicious code

into a stored procedure, allowing them to execute arbitrary commands on the server.

Prevention:
Use parameterized queries to prevent SQL injection attacks.
Sanitize user inputs to remove potentially harmful characters or commands.
Ensure that stored procedures and triggers are designed securely and only
execute the expected queries.
Regularly audit stored procedures for security vulnerabilities.
 Arbitrary Code Execution in Securable SQL Elements
Cause: Certain SQL elements, such as functions or views, are designed to be protected
(i.e., "securable"). However, attackers may exploit vulnerabilities in these elements to
execute unauthorized code.

Example: An attacker gains access to the database through a misconfigured stored

function and executes arbitrary commands that compromise database integrity.

Prevention:
Implement strict access controls for securable elements (e.g., stored functions,
triggers).
Regularly review and harden database elements like views and stored functions to
ensure they only perform necessary actions.
Limit the privileges of the database service accounts and users to reduce the scope
of potential attacks.
 Local Privilege Escalation Issues

Cause: Local privilege escalation occurs when a user or attacker gains elevated access to system-level
privileges, often through exploiting bugs or misconfigurations in the database or operating system.

Example: An attacker who has limited access on a database server exploits a misconfiguration or bug in
the operating system to gain root-level access, allowing them to access or manipulate sensitive database
files.

Prevention:
Follow the principle of least privilege by ensuring that users and processes only have the minimum
necessary permissions.
Regularly apply security patches to the operating system and database to close any known
vulnerabilities.
Implement system hardening practices, such as disabling unnecessary services, removing unused
accounts, and restricting access to sensitive files.
Conduct regular penetration testing to identify potential privilege escalation pathways.
 Privilege Escalation via SQL Injection
Cause: SQL injection occurs when an attacker inserts malicious SQL code into a query,
which the database then executes. If not properly sanitized, the attacker can escalate
their privileges, gaining unauthorized access to the database.

Example: An attacker exploits a login form by entering a malicious query like ' OR 1=1 --,
which bypasses the authentication check and grants the attacker admin access to the
database.

Prevention:
Always sanitize user inputs to remove characters that could be used in SQL injection
attacks (e.g., --, ;, ').
Use prepared statements or parameterized queries to ensure that user input cannot
alter the structure of SQL queries.
Regularly audit your applications for potential SQL injection vulnerabilities, especially
in places where user input is used in queries.