-
Notifications
You must be signed in to change notification settings - Fork 648
PageKit > Cross-site scripting (DOM-based) #962
Comments
And no one even replied to this? Amazing. |
Pagekit is (almost) dead. I suggest to head over to biskuit cms (Pagekit fork) |
I don't see how this is possible. The field is filled with either content comming from the database or with content coming from the page user currently visiting the page. Nothing is used from the URL. Additionally, dupe of #815 |
Well, it is literally explained in the OP how it works. If a logged in user navigates to a purposely crafted url their session might get stollen. For example by clicking the link in the comments. This is not something new. |
There is a generic explanation on how such attacks could work. However, it is not stated that this is always possible. In this specific scenario I don't see a possible attack here. Nothing from the URL is passed to the textarea, the textarea is only filled by the user or from server side. The user has to be logged in and have access to the admin panel (which should be granted to trusted users, only). However, I am open to be convinced by the opposite by a working example.
User entered content in the comments is not using this editor component and additionally is sanitized.
The attack vector is not something new. But, to be a threat it is also require that it can be exploited. And in this particular scenario, I don't see a possibility to exploit. |
Have you inspected an example provided by OP? He managed to inject a code into into DOM via CrossSite request. P.S. PageKit development is dead anyway so yeah. |
I just see a statement that if a textare on the page is filled with a specific value, then this value is printed to the page. This is correct as this is the design of an HTML editor. However, I don't see steps to reproduce this issue. So, there is nothing I could check. I just see a code analysis of a tool from where I don't get what I have to do to reproduce the issue. |
Problem
We have run BurpSuit(Security Scan tool) on our PageKit project and it was providing high-risk bugs in codemirror.js which is internally used in editor.js in Pagekit.
Report Details
Cross-site scripting (DOM-based)
/admin/site/page/editIssue detail:
Issue background
DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.
DOM-based cross-site scripting arises when a script writes controllable data into the HTML document in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.
Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.
Issue remediation
The most effective way to avoid DOM-based cross-site scripting vulnerabilities is not to dynamically write data from any untrusted source into the HTML document. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing script code into the document. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitize or encode the data. This can be a complex task, and depending on the context that the data is to be inserted may need to involve a combination of JavaScript escaping, HTML encoding, and URL encoding, in the appropriate sequence.
References
Vulnerability classifications
Request:
Response:
<!DOCTYPE html>
<html lang="en-US">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, i
Dynamic analysis:
Data is read from textarea.value and passed to jQuery.html.
The following value was injected into the source:
The previous value reached the sink:
The stack trace at source was:
The stack trace at the sink was:
This was triggered by a load event.
Is there any way to fix this issue? Thanks in advance!!
Technical Details
The text was updated successfully, but these errors were encountered: