Web Application Firewall

• Web Application Firewall (WAF)

WAFs are designed to protect web applications/servers from web-based attacks that IPSs cannot prevent.
WAFs can be network or host based.
They sit in-line and monitor traffic to and from web applications/servers
Basically, the difference is in the level of ability to analyze the Layer 7 web application logic.

• The world's most advanced Open Source vulnerability scanner and manager

http://www.openvas.org/ 

• Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.[1][2] The technology differs from perimeter-based protections such as firewalls, that can only detect and block attacks by using network information without contextual awareness.[3][4] RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.[5] RASP-protected applications rely less on external devices like firewalls to provide runtime security protection. When a threat is detected RASP can prevent exploitation and possibly take other actions, including terminating a user's session, shutting the application down, alerting security personnel and sending a warning to the user.[6][7] RASP aims to close the gap left by application security testing and network perimeter controls, neither of which have enough insight into real-time data and event flows to either prevent vulnerabilities slipping through the review process or block new threats that were unforeseen during development.[8]

https://en.wikipedia.org/wiki/Runtime_application_self-protection

• Runtime Application Self-Protection (RASP).

It shifts the focus from finding all vulnerabilities and remediating fast, to reducing the likelihood of breaches occurring in the first place by blocking the exploitation. It fills significant app security gaps left by earlier technologies such as WAFs
https://www.immun.io/use-case-runtime-application-self-protection-rasp

While, there may be some use cases where RASP can fully replace a WAF, the reality is both technologies have their own strengths and weaknesses and should be looked at as important layers for defense-in-depth.
WAFs provide broad perimeter defenses (generally at the data center level) and mitigate threats at the edge of your network. At face value, this is an attractive value proposition, but the deficiencies of WAF are generally only seen during the post-implementation phase when it comes to operating and maintaining the solutio
https://www.veracode.com/blog/2016/02/pragmatic-approach-leveraging-waf-and-rasp

• IAST or Interactive Application Security Testing.

For example, SAST has a difficult time dealing with libraries and frameworks found in modern apps. That’s because static tools only see the code they can follow. What’s more, libraries and third­party components often cause static tools to choke, producing “lost sources” and “lost sinks” messages. The same is true for frameworks. Run a static tool on an API, web service or REST endpoint, and it won’t find anything wrong in them because it can’t understand the framework.
IAST is designed to address the shortcomings of SAST and DAST by combining elements of both approaches. IAST places an agent within an application and performs all its analysis in the app in real-time and anywhere in the development process IDE, continuous integrated environment, QA or even in production.

Because the IAST agent is working inside the app, it can apply its analysis to the entire app ­­ all its code; its runtime control and data flow information; its configuration information; HTTP requests and responses; libraries, frameworks and other components; and backend connection information. Access to all that information allows the IAST engine to cover more code, produce more accurate results and verify a broader range of security rules than either SAST or DAST.

RASP, or Run-time Application Security Protection As with IAST, RASP, or Run­time Application Security Protection, works inside the application, but it is less a testing tool and more a security tool. It’s plugged into an application or its run­time environment and can control application execution. That allows RASP to protect the app even if a network’s perimeter defenses are breached and the apps contain vulnerabilities missed by the development team. RASP lets an app run continuous security checks on itself and respond to live attacks by terminating an attacker’s session and alerting defenders to the attack




https://www.softwaresecured.com/what-do-sast-dast-iast-and-rasp-mean-to-developers/

• Homograph attack has been known since 2001, but browser vendors have struggled to fix the problem. It’s a kind of spoofing attack where a website address looks legitimate but is not because a character or characters have been replaced deceptively with Unicode characters.

https://thehackernews.com/2017/04/unicode-Punycode-phishing-attack.html

• OWASP top 10 vulnerabilities

the top 10 web application security risks worldwide as determined by the Open Web Application Security Project.
https://www.ibm.com/developerworks/library/se-owasptop10/

• Broken Access Control

Description

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 the user's limits. Common access control vulnerabilities include:

https://owasp.org/Top10/A01_2021-Broken_Access_Control/

• How to mitigate the risk of Sensitive Data Exposure?

Prepare a threat model to secure data both in transit and at rest from both types of the attacker( e.g., insider attack, external user)

Encrypt data to protect it from any cyber attack.

Never store sensitive data unnecessarily. Discard it as soon as possible.

https://allabouttesting.org/top-10-interview-questions-owasp-top-10-application-security/

• Insecure deserialization

demonstrate some widely applicable techniques using concrete examples of PHP, Ruby, and Java deserialization

What is serialization?

Serialization is the process of converting complex data structures, such as objects and their fields, into a "flatter" format that can be sent and received as a sequential stream of bytes. Serializing data makes it much simpler to:

    Write complex data to inter-process memory, a file, or a database

    Send complex data, for example, over a network, between different components of an application, or in an API call

Serialization vs deserialization

Deserialization is the process of restoring this byte stream to a fully functional replica of the original object, in the exact state as when it was serialized. 

What is insecure deserialization?

Insecure deserialization is when user-controllable data is deserialized by a website. This potentially enables an attacker to manipulate serialized objects in order to pass harmful data into the application code.

It is even possible to replace a serialized object with an object of an entirely different class. Alarmingly, objects of any class that is available to the website will be deserialized and instantiated, regardless of which class was expected. For this reason, insecure deserialization is sometimes known as an "object injection" vulnerability.

An object of an unexpected class might cause an exception. By this time, however, the damage may already be done. Many deserialization-based attacks are completed before deserialization is finished. This means that the deserialization process itself can initiate an attack, even if the website's own functionality does not directly interact with the malicious object. For this reason, websites whose logic is based on strongly typed languages can also be vulnerable to these techniques. 

How do insecure deserialization vulnerabilities arise?

Ideally, user input should never be deserialized at all. 

However, sometimes website owners think they are safe because they implement some form of additional check on the deserialized data. This approach is often ineffective because it is virtually impossible to implement validation or sanitization to account for every eventuality.These checks are also fundamentally flawed as they rely on checking the data after it has been deserialized, which in many cases will be too late to prevent the attack. 

In short, it can be argued that it is not possible to securely deserialize untrusted input. 

What is the impact of insecure deserialization?

It allows an attacker to reuse existing application code in harmful ways, resulting in numerous other vulnerabilities, often remote code execution. 

Even in cases where remote code execution is not possible, insecure deserialization can lead to privilege escalation, arbitrary file access, and denial-of-service attacks. 

How to prevent insecure deserialization vulnerabilities

Generally speaking, deserialization of user input should be avoided unless absolutely necessary.

If you do need to deserialize data from untrusted sources, incorporate robust measures to make sure that the data has not been tampered with. For example, you could implement a digital signature to check the integrity of the data. However, remember that any checks must take place before beginning the deserialization process. Otherwise, they are of little use. 

If possible, you should avoid using generic deserialization features altogether. Serialized data from these methods contains all attributes of the original object, including private fields that potentially contain sensitive information. Instead, you could create your own class-specific serialization methods so that you can at least control which fields are exposed. 

https://portswigger.net/web-security/deserialization

• Understanding IDOR Vulnerability

A Direct Object Reference is a web application design method in which entity names are used to identify application-controlled resources that are passed in URLs or request parameters.

Insecure Direct Object Reference represents a vulnerable Direct Object Reference. It involves replacing the entity name with a different value without the user’s authorization. As a result, users will be directed to links, pages, or sites other than the ones they intended to visit,

Generally, IDOR attacks are of two types:

    Body Manipulation. Attackers modify the value of a checkbox, radio buttons, and form fields. This lets them access information from other users with ease.

    URL Tampering. The URL is modified at the client’s end by tweaking the parameters in the HTTP request. HTTP verbs GET and POST are typically vulnerable to a URL tampering IDOR attack.

Preventing IDOR Vulnerability

An Indirect Reference Map is an alternative design method to ‘Direct Object Reference’ that helps businesses avoid IDOR vulnerabilities. It replaces the actual references (such as user IDs, names, keys, etc.) with alternate IDs that map to the original values. The mapping between the alternate IDs and actual references are maintained safely on the servers.

Validate User Access

Servers fail to identify tampered URLs because there are no access checks in place at the data-object level. Data layer access controls should be enforced only when the server verifies whether the current user owns or has access permissions to the requested data.

The application should establish criteria for incoming input, and if it doesn’t meet expectations, reject the value.

https://spanning.com/blog/insecure-direct-object-reference-web-based-application-security-part-6/

• A10:2021 – Server-Side Request Forgery (SSRF)

Description

SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL)

https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/

• OWASP Benchmark Project

The OWASP Benchmark for Security Automation (OWASP Benchmark) is a free and open test suite designed to evaluate the speed, coverage, and accuracy of automated software vulnerability detection tools and services (henceforth simply referred to as 'tools'). 
You can use the OWASP Benchmark with Static Application Security Testing (SAST) tools, Dynamic Application Security Testing (DAST) tools like OWASP ZAP and Interactive Application Security Testing (IAST) tools.


https://www.owasp.org/index.php/Benchmark#tab=Mains

A WAF is an appliance or software that Monitors HTTP/HTTPS traffic and can Block malicious

traffic to and from a web application. It differs from a traditional edge firewall in that it Targets

the content from specific web applications and at the application level, while edge firewalls

fashion secure gateways between the local area network and outside servers at the network

level. Specifically, by inspecting HTTP traffic, a WAF can stop attacks originating from web

application security flaws, such as SQL injection, cross-site scripting, file inclusion, and security

misconfiguration

WAF

couldn’t rely on traditional edge firewall methods that based decisions on a blocklist of network

addresses, and blocked certain protocols and port numbers. As all web applications used HTTP

and either port 80 or 443, this approach wasn’t very useful.

The First generation of WAFs used Blocklists and

Signature-based HTTP attributes to alert the firewall of an attack, so a SQL injection attack, like

this, was no longer successfu

In the next generation, WAFs became more

intelligent—there was an Element of learning by the firewall. The WAF would learn the

behavior of the application to create a baseline it could use to evaluate whether attempts to

access the applications were normal or irregular, and therefore suspect. It also introduced

Session monitoring and heuristics, which permitted the firewall to detect variants of known

signatures.

The logical turn in WAF development was Machine-learning unencumbered by human

supervision. Now Behaviour analysis could be done at machine speed and could adapt to the

ever changing attributes of the threat. Other security features were augmented to the firewall.

Among these assets were:

Distributed Denial of Service DDoS defense

IP reputation

Antivirus

Data Loss Prevention DLP

The firewall could Monitor HTTP and stop any action that violated acceptable behavior. It could

Identify the user and correlate the action they were attempting to do with their permissions,

and Stop any action that went Beyond the scope of their role

The WAF was also designed to

Share information and collaborate with other security devices in the network, such as other

firewalls and sandboxes.

sandboxing allowed suspicious material to

be tested safely in isolation from the network. Zero-day attacks could be exposed and

quarantined in these sandbox environments, and their signatures could be shared with other

devices in the network. In addition, these new discoveries could be uploaded to a threat

intelligence center on the internet, where they could be communicated to other networks.

https://training.fortinet.com/pluginfile.php/1625623/mod_scorm/content/1/story_content/external_files/NSE%202_WAF%20Script_EN.pdf