Project

General

Profile

Actions

Feature #13286

closed

webConfigurator does not redirect to requested page after login

Added by → luckman212 almost 2 years ago. Updated almost 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Web Interface
Target version:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Default

Description

Something that has bugged me for a while now is that if you are logged out of pfSense, and request a "deep" page e.g. https://my.pfsense.lan/services_unbound.php, you will be shown the login page, but after successfully logging in, you are placed on the dashboard instead of the originally requested page.

This makes bookmarking specific pages impossible.

Here's a small PR that adds this capability.

Tested on 22.05.r.20220617.0613

Actions #2

Updated by Jim Pingle almost 2 years ago

  • Status changed from Pull Request Review to Rejected

This is done on purpose for security reasons. Until the entire GUI is purged of any page that takes action on GET, the user could be tricked into following a link that takes a harmful action.

We've made good progress on getting most things converted to POST w/CSRF validation but it's not yet 100%.

Actions #3

Updated by → luckman212 almost 2 years ago

Not sure I follow how this makes it any less secure than it already is. If a user is logged in already, they can still click on a malicious link... what part of this change makes the attack surface larger?

Actions #4

Updated by Jim Pingle almost 2 years ago

Doesn't have to be an attack, they could also do it unintentionally by bookmarking or hitting a page from their history that does it.

Just because they can do it while logged in doesn't mean it should be allowed when they aren't. It's an extra layer of protection, part of defense in depth.

Actions #5

Updated by → luckman212 almost 2 years ago

But, again- nothing prevents a logged in user from bookmarking a page or recalling one from history that actions something unintentional NOW. So this change doesn't really move that needle one way or the other.

What about if I modify it so it only takes you to the base URI (strips away all parameters/arguments). Would that be acceptable?

edit: I went ahead and did this anyway. Instead of stripping the params (which, as Jim Pingle mentions, breaks some pages) it simply ignores the redirecturi if it contains params. See patch v2

Actions #6

Updated by Jim Pingle almost 2 years ago

Some pages require parameters to load the right view, so stripping the parameters isn't helpful.

It is not going to be allowed in any form.

Actions #7

Updated by → luckman212 almost 2 years ago

I understand.

To be honest, one of my main reasons for wanting this merged was because my dashboard takes so darn long to display (close to 5 whole seconds).

So, I hope this can get reconsidered once that POST / CSRF work is complete.

Is there a redmine for that to track progress?

Actions

Also available in: Atom PDF