Vulnerability Protection
Every now and then a major security flaw is announced or even abused. For sure that's a little bit unpleasant. If you care about the security of your web applications, Nette Framework is frankly the best choice for you.
Cross-Site Scripting (XSS)
Cross-Site Scripting is a site disruption method using unescaped input. An attacker may inject his own HTML or JavaScript code and change the look of the page or even gather sensitive information about users. Protection against XSS is simple: consistent and correct escaping of all strings and inputs. Traditionally, it would be enough if your coder made just one slightest error and forgot once, and the whole website could be compromised.
An example of such an injection may be slipping the user an altered URL, which inserts a “malicious” script. If an application does not escape its inputs properly, such a request would possibly execute a script on the client's side. This may, for example, lead to stolen identity.
https://example.com/?search=<script>alert('XSS attack.');</script>
Nette Framework comes up with a brand new technology of Context-Aware Escaping, which will get you rid of the Cross-Site Scripting risks forever. It escapes all inputs automatically based on a given context, so it's impossible for a coder to accidentally forget something. Consider the following template as an example:
<p onclick="alert({$message})">{$message}</p>
<script>
document.title = {$message};
</script>
The {$message} command prints a variable. Other frameworks do often force developers to explicitly declare
escaping, and even what type of escaping based on the context. Yet in Nette Framework you don't need to declare anything.
Everything is automatic, consistent and just right. If we set the variable to $message = 'Width 1/2"', the framework
will generate this HTML code:
<p onclick="alert("Width 1\/2\"")">Width 1/2"</p>
<script>
document.title = "Width 1\/2\"";
</script>
Cross-Site Request Forgery (CSRF)
A Cross-Site Request Forgery attack is that the attacker lures the victim to visit a page that silently executes a request in the victim's browser to the server where the victim is currently logged in, and the server believes that the request was made by the victim at will. Server performs a certain action under the identity of the victim but without the victim realizing it. It can be changing or deleting data, sending a message, etc.
Nette Framework automatically protects forms and signals in presenters from this type of attack. This is done by preventing them from being sent or called from another domain. To turn off protection, use the following for forms:
$form->allowCrossOrigin();
or in the case of a signal, add an annotation @crossOrigin:
/**
* @crossOrigin
*/
public function handleXyz()
{
}
In Nette Application 3.2 you can also use attributes:
use Nette\Application\Attributes\Requires;
#[Requires(sameOrigin: false)]
public function handleXyz()
{
}
URL Attack, Control Codes, Invalid UTF-8
Different terms all related to the attacker's effort to give your application a “malicious” input. The results may vary greatly, from broken XML outputs (i.e. malfunctioned RSS stream) to getting sensitive information from an database to getting user passwords. Protection against these attacks is consistent UTF-8 check on byte level. And frankly, you would not do that without a framework, right?
Nette Framework does this for you, automatically. You don't have to configure anything at all and your application will be safe.
Session Hijacking, Session Stealing, Session Fixation
Session management involves a few types of attacks. The attacker may steal the victim's session ID or forge one and thus gain access to a web application without the actual password. Then the attacker may do whatever the user could, without any trace. The protection lies in proper configuration of both PHP and the web server itself.
Nette Framework configures PHP automatically. Developers thus do not have to worry about how to make a session protected enough
and can fully focus on the key parts of the application. This requires the ini_set() function to be enabled.
SameSite Cookie
SameSite cookies provide a mechanism for recognizing what led to a page load. Which is absolutely crucial for security reasons.
The SameSite flag can have three values: Lax, Strict and None (it requires HTTPS). If a
request for a page comes directly from the web itself or the user opens the page by directly entering it in the address bar or
clicking on a bookmark, the browser sends all cookies to the server (ie with the flags Lax, Strict and
None). If a user comes to website via click on link from another website, cookies with the Lax and
None flags will be passed to the server. If the request arises in another way such as sending a POST form from
another origin, loading inside an iframe, using JavaScript, etc., only cookies with the None flag will be sent.
By default, Nette sends all cookies with the Lax flag.
