Top 10 Threats of Web Security

Threats of Web Security

As a User's we use a lot of websites from shopping for something online, reading e-books to transferring money but sometimes we never give attention to some details. Is the website I am using safe? Am I spied on by someone or personnel details of me are compromised? Or is the link I am clicking loading in secure mode or not? Because we often think it’s not our duty, that’s where cyber attackers come into the picture phishing our data and companies, too making a huge loss to users and sometimes shutting down a company. In this article, I’ll discuss the top 10 threats to a website and respective defenses that a developer should try. Some users should know for better browsing.

1. SQL Injection

SQL injection is a code injection technique used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g., to dump the database contents to attacker).

SQL Injection Attack

For example, when a user inputs a username and password, the information is compared with the website’s database using SQL statements. This statement below could be exploited to steal data.

txtUserId = getString("UserId")
txtSQL = SELECT * FROM Users WHERE UserId = '' + txtUserId;

If there is no protection or way to prevent a user from entering invalid inputs, the user could enter calculated SQL statements. For example, an unknown visitor could enter a “crafted” input in the username field, such as “1999 OR 1=1”.

SELECT * FROM Users WHERE UserId = 105 or 1=1;

However, with this crafted input, something else happens. The invalid input “105 OR 1=1” was designed by the hacker to intentionally create a brand-new query. For example, OR 1=1 means “always TRUE”. It makes the database return all row values from the Users' table.

Common Defenses

• Prepared Statements with Parametrized SQL Queries.
• Always validate user input for whitelisting unauthorized users.
• It is important to restrict access rights to the specific users, accounts, or computer processes that are needed to perform a specific activity on the database.

2. Broken Authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly. This allows attackers to compromise passwords, keys, session tokens, or to exploit other implementation flaws and assume other users’ identities.

Broken Auth and Session Management

Understanding Hijacking

• Auth Cookie theft
  1. Sniff it over an insecure connection.
  2. Exploit a XSS risk.
  3. Retrieve from victims PC.
• Session ID theft
  1. Copy and paste the URL with session ID.
  2. Send it via insecure email.
  3. Retrieve it from a web log.
• Account Management Attack
  1. Discover Weak Credentials.
  2. Exploit password reset.
  3. Brute forces the login.

Common Defenses

• Protect the cookies (Make sure they are sent over secure connection).
• Decrease the window of risk (Either expiring session quickly or re-challenge users on key actions).
• Harden the account management (always encourage strong credentials and implement logging rate and locking).

3. XSS Risks

Cross-site Scripting (XSS) is a security vulnerability usually found in websites and/or web applications that accept user input. Examples of these include search engines, login forms, message boards and comment boxes

XSS Risks

Common Defenses

• Whitelist Untrusted Data (What input do we trust? & Does input adhere to the expected pattern?).
• Always encode output (never simply reflect untrusted data).
• Encode your resources for context (HTML, CSS, or JavaScript).

4. Insecure and Direct Object References

Insecure direct object reference is a type of access control vulnerability in digital security. This can occur when a web application or application programming interface uses an identifier for direct access to an object in an internal database but does not check for access control or authentication.

Insecure and Direct Object Reference

Common Defenses

• Implement Access Controls (Be explicit about who can access resources & always expect the rules to be tested).
• Use Indirect Maps (Don’t expose internal keys externally — map them to temp ones).
• Avoid Predictable Keys (such as incremental integers or natural keys).

5. 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 Misconfiguration

Common Defenses

• Always harden the installation (Turnoff feature that isn’t needed & apply the “principle of least privilege”).
• Tune the app security config (Ensure its production ready & remove default credentials and any other paths etc.).
• Ensure Packages are up-to date (Be conscious about 3rd party tool risks & have a strategy to monitor and update).

6. Sensitive Data Exposure

Sensitive Data Exposure occurs when an organization unknowingly exposes sensitive data or when a security incident leads to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of, or access to sensitive data.

Sensitive Data Exposure

Understanding Sensitive Data Attacks

• Insufficient Use of SSL
  1. Cookies not sent securely.
  2. Login not loaded over HTTPS
  3. Mixed Mode.
• Bad Crypto
  1. Poor protection of keys
  2. Weak algorithm chosen
  3. Incorrect password storage
• Other Exposure Risk
  1. Disclosure Via URL
  2. Browser Auto complete
  3. Leaked via logs

Common Defenses

• Minimize Sensitive Data Collection (reduce window of storage for sensitive info).
• Apply HTTPS Everywhere
• Use Strong Crypto Storage and hashing algorithms.

7. Missing Functional Level Access Control

The missing function level access control vulnerability allows users to perform functions that should be restricted, or lets them access resources that should be protected. Normally, functions and resources are directly protected in the code or by configuration settings, but it’s not always easy to do correctly.

Missing Functional Level Access

Common Defenses

• Define a clear authorization model (Use roles and apply membership).
• Check for forced browsing (check for default framework resources & try using automated scanners).
• Always test for unprivileged roles (capture & reply privileged requests).

8. Cross-site Request Forgery

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website where unauthorized commands are submitted from a user that the web application trusts.

Cross-Site Request Forgery

Understanding CSRF

Assume a case where a victim is trying to authenticate a bank portal for online money transfer and now the attacker hijacks the session and changes the account number from the body of the request.

When request send URL contains
resource: HTTP POST https://mybank.com/transfer
Auth cookie: 87e00954......
body: { TargetAccNum: 12345678, Amount: 1,00,000} 
which are modifiable sometimes and collect money in wrong way which might not noticed by user

Common Defenses

• Employ anti-forgery tokens (tokens add randomness to requests).
• Validate the referrer (Valid request don’t originate externally & the referrer is in each request header).
• Other defenses (fraud detection patterns).

9. Using Components with known vulnerabilities

Software that has been identified as unprotected and vulnerable to an attack. For example, bugs in Web servers, Web browsers and email client software are widely exploited for malicious purposes.

Using components with known vulnerabilities

Understanding

First here the attacker tries to request a page using potentially vulnerable components which are then identified by the loaded page or getting the versions of components somewhere on the page. Then the attacker tries searching for exploitable risks and attacks the website for a huge loss for its owners.

Common Defenses

• Identify components & versions.
• Components should be monitored.
• Keep components updated.

10. Unvalidated Redirects & Forwards

Unvalidated redirect vulnerabilities occur when an attacker can redirect a user to an untrusted site when the user visits a link on a trusted website. This vulnerability is also often called Open Redirect.

unvalidated redirects & forwards

Common Defenses

• Where possible, have the user provide a short name, ID or token which is mapped server-side to a full target URL (provides the highest protection against the attack tampering with the URL).
• If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is allowed for the user.
• Sanitize input by creating a list of trusted URLs (lists of hosts or a regex).

Conclusion

Finally, on leaving note, we should always thank the advancements of the web that we are using every second to plan our movements at the same time. It's time to be careful of what we are using and developing for our consumers because one tiny way into our site can sometimes lead to a huge property and personnel loss.