Navigation
Hidden security features¶
Malicious attackers can try to bypass any access control (or even validation) that a programmer may have put in place. Reahl safeguards against such attacks – in most places without your having to worry about it. Even so, a careful programmer would like to know what happens under the covers to protect against breaches, and would want to be able to direct the underlying mechanisms.
One form of attack concerns Buttons and Inputs. The server may have
served a page containing a Button or Input that is greyed out in order
to prevent the user from invoking an Action or from supplying input
via the Input (respectively). A user could edit the HTML that was
served to make these elements active again, and in this way try to
forcibly click on a Button or supply input.
This sort of attack is automatically stopped on the server side. Since
all the access control rules are available on the server, each
incoming request is checked against them as well. Attempts to click on
Buttons that were originally rendered greyed out, or to supply input
to an Input that should be greyed out are dealt with by the server as
invalid input. So, there’s nothing a programmer need to do in order to
safeguard the rules that have been put in place.
A malicious user still has the option of snooping on network traffic between the server and the client browser on order to learn sensitive information, such as a password. Some safeguarding does happen automatically here, but the programmer may have to give some clues as to what information needs to be protected.
If there are Widgets that are deemed security sensitive on a
particular page, that page is served via encrypted connection. Button
clicks originating from it are also sent via encrypted connection.
A programmer can explicitly mark a Widget as being security
sensitive. However, it is sometimes possible to derive the security
sensitivity (or not) of a Widget automatically:
By default Widgets have no access rights set for reading. By giving a
particular Widget a read_check method, the programmer informs the
system that there’s a chance that someone should not be able
to read the contents of the Widget. In such a case the Widget is
automatically deemed as being security sensitive.
In the case of Input Widgets, the same inference is made from the
access rights of the Field to which it is linked.
Thus, in many cases the framework is able to detect when something
should be served via encrypted connection, but the programmer can also
force this behaviour simply by explicitly marking a Widget as security
sensitive. This is done by calling the .set_as_security_sensitive()
method on a Widget.
In this example, the PasswordField is security sensitive, since a
PasswordField is never allowed to be read. You will notice the effect
of this when logging into the application for the first time: the home
page will be served via HTTPS.