ProcessWire v3.0.200 was discovered to contain a Cross-Site Request Forgery (CSRF).

    // Render your site’s primary navigation
    echo $pages->get('/')->children->each('<li><a href={url}>{title}</a>');

    // Find buildings: built before 1950, 10+ floors, sort by height
    $pages->find('template=building, year<1950, floors>=10, sort=height');

    // Output field “headline” when present or “title” if not
    echo '<h1>' . $page->get('headline|title') . '</h1>';

    // Get “email” field from /contact/ page and use it in link
    <a href='mailto:<?= $pages->get('/contact/')->email ?>'>Email</a>

    // Output first “images” field item on page at 90px width
    <img src='<?= $page->images->first->width(90)->url ?>'>

    // Set “headline” field value on page and save to database
    $page->setAndSave('headline', 'Hello world');

**Every bit of content in your site is never more than 1-line of code away.** It doesn’t matter how large or small your site is, with ProcessWire all your content is connected, making it fast and easy to find, and incredibly simple to access, output and manipulate.

**All fields in ProcessWire are custom fields that you easily define and edit in the admin.** You can create as many of them as you want, and of any type. You can even bundle them in repeatable groups called Repeater fields. ProcessWire is built to adapt to _your_ content needs.

**Every field has a type and there are dozens of different types.** It’s all here—text, rich text, numbers, files, images, multi-language, dates, page references, custom repeatable groups, and on and on… plus you can easily add more, since they are plugins/modules!

CVE-2022-40488: ProcessWire: An open source CMS with a powerful API

A Cross-Site Request Forgery (CSRF) in dzzoffice 2.02.1_SC_UTF8 allows attackers to arbitrarily create user accounts and grant Administrator rights to regular users.

**dzzoffice****官方网站:http://dzzoffice.com****演示地址:http://demo.dzzoffice.com****DzzOffice 介绍：**

Dzzoffice是一套开源办公套件，适用于企业、团队搭建自己的 类似“Google企业应用套件”、“微软Office365”的企业协同办公平台。套件由多个工具组成，包含但不限于如：

**网盘**: 企业、团队文件集中管理。主要体现的功能是支持企业部门的组织架构建立共享目录，也支持组的方式灵活建立共享目录。支持文件标签，多版本，评论，详细的目录权限等协作功能。

**文档**: 在线 Word 文档协作工具。前端做了一套模板管理，用于企业添加自己的常用文档模板，如空白合同。后端支持 office online server，onlyoffice，collaboraoffice 来实现文档预览与协同编辑。

**表格**: 在线 Excel 协作工具。同上

**演示文稿**: 在线 PPT 文档浏览、编辑工具。同上

**记录**: 多人参与协作的记录本，主要体现协作记录内容。

**新闻**: 文章系统，可用于企业新闻，通知等用途

**通讯录**: 企业人员联系方式查询

**文集**: 通过树形目录有序管理文档。支持 Markdown 编辑，支持导入导出 txt，epub、mobi、azw3

**相册**： 企业，团队图片管理

**任务板**: 任务管理、团队协作

**讨论板**: 内部论坛设置

**表单**: 表单，问卷工具

企业根据需要可以只使用一款工具，也可以多款工具组合使用。例如团队需要一个任务管理工具，可以只安装一个任务板，登陆系统会直接进入任务板工具，没有其他工具的干扰。如果多个工具组合使用，可以设置默认登陆到哪个工具里。

除了以上自己开发了一些工具，套件里还集成了大量的其他开源工具，如网盘里用到的在线压缩、解压，各类媒体文件预览，各类文档预览与编辑的支持，是各类开源程序的综合利用。

**DzzOffice2.01主要更新内容**

1.  增加 云设置和管理 ，支持阿里云存储、七牛云存储、FTP/SFTP、本地磁盘等存储方式；
    
2.  增加 用户资料管理 ，支持自定义用户资料项，资料审核、认证和审核；
    
3.  修改应用市场应用在线安装方式，提高应用下载速度；
    
4.  增加伪静态支持，可以通过应用“伪静态管理”灵活配置各个页面的伪静态规则；
    
5.  机构和用户管理 优化添加部门管理员的体验；
    
6.  导入导出用户功能优化调整；
    
7.  部分页面移动端适配；
    
8.  增加首次安装引导页，引导管理员首次能正确配置系统；
    
9.  开放讨论板应用（可在应用市场内在线安装）；
    
10.  开放任务板应用（可在应用市场内在线安装）；
    
11.  其他功能完善、及beta版反馈问题的修复；
    

**DzzOffice在线更新方法**

1.  进入您原来的系统，关闭您的站点。进行数据备份；
    
2.  备份文件（如果有程序文件或风格文件的改动）；
    
3.  进入 管理 -> 系统工具 -> 在线更新，按提示完成更新任务；
    
4.  系统工具 -> 更新系统缓存；
    
5.  系统设置 -> 打开站点。
    

**DzzOffice离线更新方法（仅支持从2.0beta版升级）**

1.  进入您原来的系统，关闭您的站点。进行数据备份；
    
2.  备份文件（如果有程序文件或风格文件的改动）；
    
3.  下载并解压缩最新版的程序包；
    
4.  程序包解压缩后，并且将文件上传到网站根目录覆盖；
    
5.  访问 http://您的域名/install/update.php。
    
6.  按照程序提示，直至所有升级完毕。删除install/update.php 程序，以免被恶意利用。
    
7.  进入管理员桌面，更新缓存。
    
8.  系统设置 -> 打开站点。

CVE-2022-43340: GitHub - zyx0814/dzzoffice: dzzoffice

Incomplete filtering of JavaScript code in different configuration fields of the web based interface of the VIDEOJET multi 4000 allows an attacker with administrative credentials to store JavaScript code which will be executed for all administrators accessing the same configuration option.

**Advisory Information**

*   **Advisory ID:** BOSCH-SA-454166-BT
*   **CVE Numbers and CVSS v3.1 Scores:**
    *   CVE-2022-40183
        *   Base Score: 5.8 (Medium)
    *   CVE-2022-40184
        *   Base Score: 5.1 (Medium)
*   **Published:** 19 Oct 2022
*   **Last Updated:** 19 Oct 2022

**Summary**

The possibility for a reflected Cross Site Scripting (XSS) and stored Cross Site Scripting (XSS) attack was discovered in the Bosch VIDEOJET multi 4000.

For more details please see the description of the vulnerability in this advisory.

Bosch rates this vulnerability with CVSSv3.1 base score 5.8 (medium) and 5.1 (medium), where the final rating depends on the customer’s environment.

Customers are advised to follow listed mitigations until an update is available.

**Affected Products**

*   Bosch VIDEOJET multi 4000 <= 6.31.0010

**Solution and Mitigations****Secure Configuration Environment**

It is advised to use a Bosch tool like the Configuration Manager to configure the encoder, that is not vulnerable to issues like XSS (Cross Site Scripting) or CSRF (Cross Site Request Forgery).

When using the web based configuration interface and currently being logged in as an administrator, some security precautions can be taken to mitigate XSS or CSRF vulnerabilities:

*   No other websites or email content should be opened as long as the session to the encoder is active.
    
*   No links should be clicked from an untrusted external source that link back to the encoder.
    
*   Use a different browser than the system default browser to open a session to the encoder as there is no XSS or CSRF between browsers.
    
*   Always log out and/or close the browser (not only the tab) to clear any session data.
    

**Secure Administration**

A stored XSS attack is only possible when an user with administrative rights is able to save malicious JavaScript code on the device. Only trusted users should have access to the administrative interface and common security rules for administrative credentials should be followed (e.g. using strong, unique passwords).

**Vulnerability Details****CVE-2022-40183**

CVE description: An error in the URL handler of the VIDEOJET multi 4000 may lead to a reflected cross site scripting (XSS) in the web-based interface. An attacker with knowledge of the encoder address can send a crafted link to a user, which will execute JavaScript code in the context of the user.

*   Problem Type:
    *   CWE-79 Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
*   CVSS Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:L
    *   Base Score: 5.8 (Medium)

**CVE-2022-40184**

CVE description: Incomplete filtering of JavaScript code in different configuration fields of the web based interface of the VIDEOJET multi 4000 allows an attacker with administrative credentials to store JavaScript code which will be executed for all administrators accessing the same configuration option.

*   Problem Type:
    *   CWE-79 Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
*   CVSS Vector String: CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:L/A:L
    *   Base Score: 5.1 (Medium)

**Remarks****Security Update Information**

With respect to Directive (EU) 2019/770 and Directive (EU) 2019/771 and their national transposition laws, please note:

It is your responsibility to download and/or install any security updates provided by us, for example to maintain product or data security. If you fail to install a security update provided to you within a reasonable period of time, we will not be liable for any product defect solely due to the absence of such security update.

Alternatively, we are entitled to directly download and/or install security updates regardless of your settings. In these cases, we will provide you with the relevant information, e.g. in this security advisory.

**CVSS Scoring**

Vulnerability classification has been performed using the CVSS v3.1 scoring system . The CVSS environmental score is specific to each customer’s environment and should be defined by the customer to attain a final scoring.

**Additional Resources**

*   \[1\] Firmware Download Area: https://downloadstore.boschsecurity.com/index.php?type=FW

Please contact the Bosch PSIRT if you have feedback, comments, or additional information about this vulnerability at: psirt@bosch.com .

**Revision History**

*   19 Oct 2022: Initial Publication

**Appendix****Affected Products****Bosch VIDEOJET multi 4000**

Affected VIDEOJET multi 4000 firmware

Name of version to fix the vulnerability

6.31.0010 and earlier

VIDEOJET multi Download Area

**Material Lists****VIDEOJET multi 4000**

Family Name

CTN

SAP#

Material description

VIDEOJET multi 4000

VJM-4016

F.01U.298.670

VIDEOJET multi 4000

VIDEOJET multi 4000 EU

VJM-4016-EU

F.01U.296.122

VIDEOJET multi 4000 EU

VIDEOJET multi 4000 US

VJM-4016-US

F.01U.298.556

VIDEOJET multi 4000 US

CVE-2022-40184: Multiple Cross Site Scripting vulnerabilities in Bosch VIDEOJET multi 4000

Cross-Site Request Forgery (CSRF) vulnerability in ThemeFusion Avada premium theme versions <= 7.8.1 on WordPress leading to arbitrary plugin installation/activation.

 Verified

 Fixed

**8.8**

CVSS 3.1 score High severity

Report  

Monitoring Not reported to be exploited

Vulnerable versions

<= 7.8.1

PSID 

ce884d29476d

Classification 

Cross Site Request Forgery (CSRF)

OWASP Top 10 

A5: Broken Access Control

Publicly disclosed

2022-10-20

**Details**

Cross-Site Request Forgery (CSRF) vulnerability Leading to Arbitrary Plugin Installation/Activation discovered by Dave Jong (Patchstack) in WordPress Avada theme (versions <= 7.8.1).

**Solution**

Update the WordPress Avada theme to the latest available version (at least 7.8.2).

**References**

Changelog

CVE-2022-41996: WordPress Avada premium theme <= 7.8.1 - Cross-Site Request Forgery (CSRF) vulnerability - Patchstack

The LBStopAttack WordPress plugin through 1.1.2 does not use nonces when saving its settings, making it possible for attackers to conduct CSRF attacks. This could allow attackers to disable the plugin's protections.

CVE-2022-3097

The AdminPad WordPress plugin before 2.2 does not have CSRF check when updating admin's note, allowing attackers to make a logged in admin update their notes via a CSRF attack

CVE-2022-2762

PRTG Network Monitor through 22.2.77.2204 does not prevent custom input for a device’s icon, which can be modified to insert arbitrary content into the style tag for that device. When the device page loads, the arbitrary Cascading Style Sheets (CSS) data is inserted into the style tag, loading malicious content. Due to PRTG Network Monitor preventing “characters, and from modern browsers disabling JavaScript support in style tags, this vulnerability could not be escalated into a Cross-Site Scripting vulnerability.

CVE-2022-35739: PRTG Network Monitor - Version History

myVesta Control Panel before 0.9.8-26-43 and Vesta Control Panel before 0.9.8-26 are vulnerable to command injection. An authenticated and remote administrative user can execute arbitrary commands via the v_sftp_license parameter when sending HTTP POST requests to the /edit/server endpoint.

*   \[Security\] fix for: CSRF remote code execution in UploadHandler.php - CVE-2021-28379 (Credits to: Fady Osman @fady\_othman)
*   \[Security\] fix for: Local privilege escalation from user account to admin account user via v-add-web-domain (Credits to: Two independent security researchers, Marti Guasch Jiménez and Francisco Andreu Sanz, working with the SSD Secure Disclosure program) (and also thanks to HestiaCP @hestiacp for fix)
*   \[Security\] fix for: Local privilege escalation in v-generate-ssl-cert (potential user to admin or root escalation) (Credits to: Numan Türle @numanturle, thanks to HestiaCP @hestiacp for fix)
*   \[Security\] fix for: Local privilege escalation in /web/api/ via v-make-tmp-file (probably admin to root escalation) (Credits to: Numan Türle @numanturle, thanks to HestiaCP @hestiacp for fix)
*   \[Security\] fix for: Cross site scripting in /web/add/ip/ (admin to other admin XSS escalation) (Credits to: Numan Türle @numanturle, thanks to HestiaCP @hestiacp for fix)
*   \[Security\] fix for: Admin to root escalation in v-activate-vesta-license (Credits to: Numan Türle @numanturle)
*   \[Security\] Ensure HTML will not be displayed in list log page (Credits to: Kristan Kenney @kristankenney, thanks to HestiaCP @hestiacp for fix)

CVE-2021-46850: Release Version 0.9.8-26-43 · myvesta/vesta

OpenStack Horizon fails to validate the token provided during a SAML request allowing an attacker to forge a REFERER for redirection.

    Hi,we opened a bug at OpenStack, 3 month ago, but nobody takes care about it. Due to the OpenStack guidlines the bug report is now public readable.https://bugs.launchpad.net/horizon/+bug/1980349I am not a security expert and do not know how bad this bug is, there is now CVE and so on. Please be kind.# Description of the bugWe use OpenStack horizon in the following version: `git+https://opendev.org/openstack/horizon@9d1bb3626bc1dbcf29a55aeb094f4350067317cd#egg=horizon`In Horizon there is the following code in Xena:openstack_auth/views.py```def websso(request):    """Logs a user in using a token from Keystone's POST."""    referer = request.META.get('HTTP_REFERER', settings.OPENSTACK_KEYSTONE_URL)    auth_url = utils.clean_up_auth_url(referer)    token = request.POST.get('token')    try:        request.user = auth.authenticate(request, auth_url=auth_url,                                         token=token)   ...```This call is usually called during SAML-Auth, but you can call it on the command line like this:``curl -v 'http://horizon-name:8080/auth/websso/' -X POST -H 'Referer: https://referer:5001/' -H 'Content-Type: application/x-www-form-urlencoded' --data-raw 'token=mytoken'``The token is not checked.So an attacker can control the content of the HTTP_REFERER and then an auth POST request will be sent to this address.I have changed the referer to a web server https://webserver/su-huhu/ and you can find inside the logfile:```access.log: <ip-address-of-horizon> - - [28/Jun/2022:08:15:06 +0200] "POST /su-huhu/v3/auth/tokens HTTP/1.1" 404 6529 "-" "openstack_auth keystoneauth1/4.5.0 python-requests/2.27.1 CPython/3.8.10"```# Impact* An attacker can hide his ip and do a brute force attack to any other ip via all public available horizon dashboards.* An attacker can setup a machine, set the referer to this machine and then send some ugly results (e.g. very long, never ending, wrong json code, ssl protocol issues) to the horizon service.* An attacker can analyze which services are available on the horizon host (if it is behind a firewall, use DNS Servers with private zones). Note that you are able to change the port number to any number. I have not tested, but perhaps it is also possible to change the protocol to another value, let's say: imap://user:passwort@ip/.# Is this only relevant for xenaThe code has changed on master branch, but the bug is still there:```# TODO(stephenfin): Migrate to CBV@sensitive_post_parameters()@csrf_exempt@never_cachedef websso(request):    """Logs a user in using a token from Keystone's POST."""    if settings.WEBSSO_USE_HTTP_REFERER:        referer = request.META.get('HTTP_REFERER',                                   settings.OPENSTACK_KEYSTONE_URL)        auth_url = utils.clean_up_auth_url(referer)    else:        auth_url = settings.OPENSTACK_KEYSTONE_URL    token = request.POST.get('token')    try:        request.user = auth.authenticate(request, auth_url=auth_url,                                         token=token)    except exceptions.KeystoneAuthException as exc:        if settings.WEBSSO_DEFAULT_REDIRECT:            res = django_http.HttpResponseRedirect(settings.LOGIN_ERROR)        else:            msg = 'Login failed: %s' % exc            res = django_http.HttpResponseRedirect(settings.LOGIN_URL)            set_logout_reason(res, msg)        return res```only changing the WEBSSO_USE_HTTP_REFERER to false (Default true) will forbid to call this.

OpenStack Horizon Missing Validation

Multiple open redirect vulnerabilities in NopCommerce 4.10 through 4.50.1 allow remote attackers to conduct phishing attacks by redirecting users to attacker-controlled web sites via the returnUrl parameter, processed by the (1) ChangePassword function, (2) SignInCustomerAsync function, (3) SuccessfulAuthentication method, or (4) NopRedirectResultExecutor class.

**Info**

Multiple Open Redirects in NopCommerce

Software Link

NopCommerce Web Platform

Affected Versions

4.10 - 4.50.1

Tested on

NopCommerce 4.40, 4.50.1

Vulnerable Components

src/Presentation/Nop.Web.Framework/Mvc/Routing/NopRedirectResultExecutor.cs,  
src/Presentation/Nop.Web/Controllers/CustomerController.cs,  
src/Libraries/Nop.Services/Customers/CustomerRegistrationService.cs,  
src/Libraries/Nop.Services/Authentication/External/ExternalAuthenticationService.cs

CVSS 3.0

CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N

CVE

CVE-2022-26954

**Summary**

Multiple flaws in the handling of returnurl parameter allow for multiple open redirects in the application that may be abused by an attacker to construct successful phishing campaigns on application users by crafting URLs of legitimate application that will seamlessly redirect users to attacker-controlled resources.

**Fix**

The issue was fixed in the minor NopCommerce 4.50.2 release on April 14th 2022.

Code commit with corresponding fixes

**Details**

The NopCommerce web application uses the UrlHelper.IsLocalUrl built into the C# framework to prevent open redirections when handling user-supplied URL path parameters, such as returnUrl.

...
//prevent open redirection attack
if (!Url.IsLocalUrl(returnUrl))
    return RedirectToAction("Index", "Home", new { area \= AreaNames.Admin });

return Redirect(returnUrl);
...

_Code snippet illustrating checks over returnUrl parameter prior to the redirection_

However, this defence mechanism is not consistently implemented within the application controllers. In particular, the following controller methods are missing the functionality:

*   ChangePassword (src/Presentation/Nop.Web/Controllers/CustomerController.cs)
    
    \[HttpPost\]
    public virtual async Task<IActionResult\> ChangePassword(ChangePasswordModel model, string returnUrl)
    {
      ...
    	if (changePasswordResult.Success)
      {
          \_notificationService.SuccessNotification(await \_localizationService.GetResourceAsync("Account.ChangePassword.Success"));
          return string.IsNullOrEmpty(returnUrl)  ? View(model) : new RedirectResult(returnUrl);
      }
      ...
    }
    
*   SignInCustomerAsync (src/Libraries/Nop.Services/Customers/CustomerRegistrationService.cs)
    
    public virtual async Task<IActionResult\> SignInCustomerAsync(Customer customer, string returnUrl, bool isPersist \= false)
    {
        ...
        //redirect to the return URL if it's specified
        if (!string.IsNullOrEmpty(returnUrl))
            return new RedirectResult(returnUrl);
    
        return new RedirectToRouteResult("Homepage", null);
    }
    
*   SuccessfulAuthentication (src/Libraries/Nop.Services/Authentication/External/ExternalAuthenticationService.cs)
    
    protected virtual IActionResult SuccessfulAuthentication(string returnUrl)
    {
        //redirect to the return URL if it's specified
        if (!string.IsNullOrEmpty(returnUrl))
            return new RedirectResult(returnUrl);
    
        return new RedirectToRouteResult("Homepage", null);
    }
    

The aforementioned methods do not contain any checks over the user supplied value, and thus are vulnerable to the open redirects. Open redirects can be triggered by sending the following requests to the application:

_An up-to-date build (on 17.02.2022) from the official NopCommerce GitHub was used to demonstrate the issue_

    POST /login?returnurl=https://google.com HTTP/1.1
    Host: localhost
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 242
    Origin: http://localhost
    Connection: close
    Referer: http://localhost/login?returnUrl=https://google.com
    Cookie: COOKIES
    
    Email=EMAIL&Password=PASS&__RequestVerificationToken=CSRF_TOKEN&RememberMe=false
    
    HTTP/1.1 302 Found
    Content-Length: 0
    Connection: close
    Date: Thu, 17 Feb 2022 08:11:48 GMT
    Server: Kestrel
    Cache-Control: no-cache,no-store
    Content-Language: en-US
    Expires: Thu, 01 Jan 1970 00:00:00 GMT
    Location: https://google.com
    

_Open redirect after a successful login_

    POST /customer/changepassword?returnUrl=https://google.com HTTP/1.1
    Host: localhost
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 318
    Origin: http://localhost
    Connection: close
    Referer: http://localhost/customer/changepassword
    Cookie: COOKIES
    Upgrade-Insecure-Requests: 1
    
    OldPassword=OLD_PASS&NewPassword=NEW_PASS&ConfirmNewPassword=NEW_PASS&__RequestVerificationToken=CSRF_TOKEN
    
    HTTP/1.1 302 Found
    Content-Length: 0
    Connection: close
    Date: Thu, 17 Feb 2022 09:02:15 GMT
    Server: Kestrel
    Content-Language: en-US
    Location: https://google.com/
    X-MiniProfiler-Ids: ["9d6e3a1a-9f9f-4caa-ae31-35b2332ce128"]
    

_Open redirect after a successful password change_

Furthermore, a flaw in a custom RedirectResultExecutor class, used to handle all HTTP redirects in the application, can be abused to **bypass any defence mechanisms and perform open redirects in any application controllers that use client-side supplied input (e.g., in returnUrl) to perform the redirect**.

The issue is exploitable in all versions from commit #2731 Add URL encoding on redirection to URL with non-ASCII chars(January 23, 2018) to commit #3192 Fixed URL encoding on redirect (November 24, 2021).

Code of the vulnerable NopRedirectResultExecutor.ExecuteAsync method, located in src/Presentation/Nop.Web.Framework/Mvc/Routing/NopRedirectResultExecutor.cs, is shown below:

/// <summary\>
/// Execute passed redirect result
/// </summary\>
/// <param name\="context"\>Action context</param\>
/// <param name\="result"\>Redirect result</param\>
/// <returns\>A task that represents the asynchronous operation</returns\>
public override Task ExecuteAsync(ActionContext context, RedirectResult result)
{
    if (result \== null)
        throw new ArgumentNullException(nameof(result));

    if (\_securitySettings.AllowNonAsciiCharactersInHeaders)
    {
        //passed redirect URL may contain non-ASCII characters, that are not allowed now (see https://github.com/aspnet/KestrelHttpServer/issues/1144)
        //so we force to encode this URL before processing
        result.Url \= WebUtility.UrlDecode(result.Url);
    }

    return base.ExecuteAsync(context, result);
}

The application URL-decodes the returnUrl parameter and puts it directly into the Location header of the response served to the client.

Any preceding IsLocalUrl checks can be effectively ignored by adding the second / character (char 0x27) in double-URI encoding.

For example, the payload returnUrl=%2f%252fgoogle.com will undergo the following processing:

1.  The application web server will natively decode the first layer of URL encoding and pass it to the controller:
    
    %2f%252fgoogle.com --> /%2fgoogle.com
    
2.  The controller will perform the IsLocalUrl check over the /%2fgoogle.com value:
    
    Since the second / is still being encoded as %2f , the function will return true:
    
    IsLocalUrl("/%2fgoogle.com") --> true
    
3.  The /%2fgoogle.com value will be used to call Redirect function
    
4.  The /%2fgoogle.com value will be processed by the NopRedirectResultExecutor, once more decoded into //google.com, and directly served in the Location header:
    
    result.Url \= WebUtility.UrlDecode(result.Url); // will result in "//google.com"
    ...
    return base.ExecuteAsync(context, result);
    

    [*] returnUrl value: "/%2fgoogle.com"
    [+] result.Url value: "//google.com"
    

_Verbose printing of local variables inside the NopRedirectResultExecutor during processing of an attacker-injected value_

Thus, it is possible to achieve the following server behavior in all client-side controlled redirects:

    POST /en/login?returnurl=%2F%252fATTACKER_HOST HTTP/2
    Host: localhost
    Cookie: COOKIES
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 249
    
    Username=USER&Password=PASS&__RequestVerificationToken=CSRF_TOKEN&RememberMe=false
    
    HTTP/2 302 Found
    Date: Tue, 15 Feb 2022 20:48:29 GMT
    Content-Length: 0
    Cache-Control: no-cache
    Pragma: no-cache
    Expires: Thu, 01 Jan 1970 00:00:00 GMT
    Location: //ATTACKER_HOST
    

A Location header value of //ATTACKER_HOST is actually a valid, shortened form of CURRENT_URI_SHEME://ATTACKER_HOST and will be successfully processed and followed to by modern browsers.

NopRedirectResultExecutor was partially fixed in BugFix #3192 and now uses extra processing before returning the value to the client:

/// <summary\>
/// Execute passed redirect result
/// </summary\>
/// <param name\="context"\>Action context</param\>
/// <param name\="result"\>Redirect result</param\>
/// <returns\>A task that represents the asynchronous operation</returns\>
public override Task ExecuteAsync(ActionContext context, RedirectResult result)
{
    if (result \== null)
        throw new ArgumentNullException(nameof(result));

    if (\_securitySettings.AllowNonAsciiCharactersInHeaders)
    {
        //passed redirect URL may contain non-ASCII characters, that are not allowed now (see https://github.com/aspnet/KestrelHttpServer/issues/1144)
        //so we force to encode this URL before processing
        var url \= WebUtility.UrlDecode(result.Url);

        var urlHelper \= result.UrlHelper ?? \_urlHelperFactory.GetUrlHelper(\_actionContextAccessor.ActionContext);
        
				var isLocalUrl \= urlHelper.IsLocalUrl(url);

        var uri \= new Uri(isLocalUrl ? $"{\_webHelper.GetStoreLocation().TrimEnd('/')}{url}" : url, UriKind.Absolute);
        
        result.Url \= isLocalUrl ? uri.PathAndQuery : $"{uri.GetLeftPart(UriPartial.Query)}{uri.Fragment}";      
		}
    return base.ExecuteAsync(context, result);
}

The following mutations are performed on the attacker-injected /%2fgoogle.com value:

1.  The application URL-decodes the returnUrl parameter value into a url variable.
2.  The url is checked with the built-in IsLocalUrl helper check to determine if it is relative or not.
3.  The check returns false on the decoded value//google.com , and the url is then processed as external.
4.  The application then initiates a new uri variable that uses the built-in Uri class to process the //google.com value as an absolute URL. The Uri class constructor, due to the lack of a URI scheme, will treat the value as local path and prepends a file:// schema.
5.  The uri variable is converted back to string.
6.  The resulting value is served to the client in the Location header.

Although the core weakness with bypassing the preceding IsLocalUrl checks on returnUrl values still can be exploited by an attacker to achieve an open redirect, the file:// schema that is now returned back to the browser has almost no practical impact, as it is likely ignored by the browsers’ security policies (ERROR_INSECURE_REDIRECT). However, the issue can still affect HTTP clients that use the native API for communication and data processing.

    [*] returnUrl value: "/%2fgoogle.com"
    [*] url value: "//google.com"
    [?] isLocalUrl value: False
    [*] uri value: Uri(file://google.com/)
    [+] Resulting redirect URI value: Uri(file://google.com/)
    

_New behavior processing logs from supplying /%252fgoogle.com into the returnUrl_

    POST /login?returnurl=/%252fgoogle.com HTTP/1.1
    Host: localhost
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 252
    Cookie: COOKIES
    
    Email=EMAIL&Password=PASS&__RequestVerificationToken=CSRF_TOKEN&RememberMe=false
    
    HTTP/1.1 302 Found
    Content-Length: 0
    Connection: close
    Date: Tue, 15 Feb 2022 20:40:34 GMT
    Server: Kestrel
    Expires: Thu, 01 Jan 1970 00:00:00 GMT
    Location: file://google.com/
    

_New NopRedirectResultExecutor behavior on local instance of the up-to-date (17.02.2022) application compiled from GitHub source code_

Tag

#csrf