Project

General

Profile

Actions

Bug #11628

open

Application logic attack prevention: hidden buttons (and others widgets) are clickable

Added by Dries Mys about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
Start date:
05/17/2023
Due date:
% Done:

0%

Estimated time:

Description

Your site mentions the following built-in security feature:

  • Application logic attack prevention. Only those events exposed in the interface (accessible from a button, for example) can be triggered.

I would expect that hidden widgets are considered "not being exposed" by default. From a security perspective, this seems to me the right approach. An end user should normally not be able to trigger events for such a widget.

I'm aware that sometimes you want to trigger events for hidden widgets, as they are sometimes used as a (hidden) technical implementation artefact, rather than being the real visible graphical interface. (This is the case for WFileUpload?)

WApplication::isExposed mentions that checking WWidget::isVisible should only be reenabled when all regressions are fixed. Is there some list of known regressions? The only information I could find is https://redmine.emweb.be/boards/2/topics/3475?r=3481#message-3481, but I'm not sure if this is really related, as a popup should be visible when the user clicks on it.

I would suggest to introduce a new WWidget member:

  • WWidget::isExposed: returns whether its events can be triggered. Default implementation would be: return isVisible() && isEnabled();

The exceptions to this default and secure rule, may override WWidget::isExposed (f.ex. allow triggering an upload event as long as the real GUI is effectively exposed, i.e. visible and not disabled, to the end user).

WApplication::isExposed can use this new member function instead of checking isVisible and isEnabled separately.

Actions #1

Updated by Roel Standaert about 1 year ago

  • Target version set to future
Actions

Also available in: Atom PDF