Project

General

Profile

Actions

Bug #11843

closed

Potential XSS vulnerability in Captive Portal ``redirurl`` handling

Added by Jim Pingle about 1 year ago. Updated 3 months ago.

Status:
Closed
Priority:
Very High
Assignee:
Category:
Captive Portal
Target version:
Start date:
04/22/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
21.05.1
Release Notes:
Default
Affected Version:
All
Affected Architecture:
All

Description

The value of redirurl is passed as-is from the client URL into a page result served to users in certain cases. If a logged-in captive portal user visits a manually crafted URL which contains a malicious value for redirurl, and then follows the resulting link, it could lead to JS code being executed in their browser.

It does not appear to be possible to automatically trigger the behavior or to have it be populated from the CP configuration, due to other unrelated issues (#11842 for one example) and browser behaviors. For example, the browser would refuse to redirect and instead would display a protocol violation error.

To test the behavior:

  • Configure and enable a basic captive portal instance for LAN (authentication can be disabled to keep it simple)
  • From a client on LAN, login to the portal
  • From the client, load the following URL: <portal URL>/index.php?zone=<zone name>&redirurl=javascript:alert(location)
    For example: http://192.168.1.1:8002/index.php?zone=guests&redirurl=javascript:alert(location)
  • The page will output a message stating "You are connected" including a link to the contents of redirurl
  • From the client, click the link. The JS is executed.

If the contents of redirurl are not a URL, the link should be omitted.

Actions #1

Updated by Jim Pingle about 1 year ago

  • Description updated (diff)
Actions #2

Updated by Jim Pingle about 1 year ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #3

Updated by Jim Pingle about 1 year ago

  • Plus Target Version set to 21.05
Actions #4

Updated by Jim Pingle about 1 year ago

Already in 21.05 branch.

Actions #5

Updated by Jim Pingle about 1 year ago

  • Subject changed from Potential XSS vulnerability in Captive Portal redirurl handling to Potential XSS vulnerability in Captive Portal ``redirurl`` handling

Updating subject for release notes.

Actions #6

Updated by Jim Pingle 12 months ago

  • Target version changed from 2.6.0 to 2.5.2
Actions #7

Updated by Steve Wheeler 12 months ago

  • Status changed from Feedback to Resolved

Tested this against 21.05.r.20210526.1807.

Whilst logged in:

10.2.246.12     ac:bc:32:84:78:95    unauthenticated     06/01/2021 21:50:03     

Tested:

http://10.2.246.1:8002/index.php?zone=Test_Zone&redirurl=javascript:alert(location)

Resulting page is:

You are connected.
<br/>

Actions #8

Updated by Jim Pingle 12 months ago

  • Private changed from Yes to No
Actions #9

Updated by Jim Pingle 10 months ago

  • Status changed from Resolved to In Progress
  • Target version changed from 2.5.2 to 2.6.0
  • Private changed from No to Yes
  • Plus Target Version changed from 21.05 to 21.09

Reopening since the fix here is not complete. The URL scheme isn't validated here so it is still possible to trigger by using a redirurl string such as javascript:/**/alert(1).

  • Start with a fresh install, enable captive portal (zone=guest, LAN) with no authentication.
  • Load a client on LAN and login to the portal
  • In the browser, go to the following URL:
    http://192.168.1.1:8002/index.php?zone=guest&redirurl=javascript:/**/alert(1)
    

Currently is_URL() doesn't have a way to validate the value of the URL scheme it only checks the general form. In this case only HTTP and HTTPS links make sense for usage as captive portal redirects, so it should have a way to limit validation. We can't change the default behavior of is_URL() as other areas of the code may be relying on its current behavior and we do not want to have to chase down and test the other cases.

I have a correction ready to commit, will push shortly.

Actions #10

Updated by Jim Pingle 10 months ago

  • Status changed from In Progress to Feedback
Actions #11

Updated by Jim Pingle 10 months ago

  • Plus Target Version changed from 21.09 to 21.05.1
Actions #12

Updated by Jim Pingle 9 months ago

  • Status changed from Feedback to Closed

I can no longer reproduce the problem on 2.6.0 or 21.05.1.

Actions #13

Updated by Jim Pingle 3 months ago

  • Private changed from Yes to No
Actions

Also available in: Atom PDF