-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
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
Prevent possible XSS #18289
Prevent possible XSS #18289
Conversation
- In the case of misuse or misunderstanding from a developer whereby, `data-panel` can receive user-controlled data. `$(sel)` can lead to the creation of a new element. Current usage is using hard-coded selectors in the templates, but nobody prevents that from expanding to user-controlled somehow.
The code seems to originate from the BIDI feature(#17562) so I don't think this needs to be backported. |
make LGTM work |
can we add some linter to catch this? |
Hmm interesting, this was instance was catched by a CodeQL query I've been running locally. Seems to get confused when it sees a usage that is indirect and inlined.
We might go a bit harsh and ban the usage of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to refactor all similar code together and write the rule into frontend guide, or just keep the code as it was.
Otherwise, this patch doesn't help the code base.
I'm still of the opinion we should just replace jQuery with vanilla JS, e.g. |
What's the current argument to not do this? If none, expect a PR from me soon to do this. As that would resolve this issue and future ones entirely. |
There's no blocker, it's just that some people like @zeripath seem to prefer |
I think this pull is fine as is - I do not like heavy code refactor in freezing, if it do not fix an issue ;) the ongoing discussion about how our frontend should move towards (framework, libs, ...) is important and we should overthing some of it ... - I would suggest to let this pull be reviewed against proposed aim & open a new issue/discurese-thread/... to talk about this - it look's like it (discussion) is needed :) PS: I personally like typescript - but I wont vote for a specific direction as UI is not my main domain ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fast, awesome.
Codecov Report
@@ Coverage Diff @@
## main #18289 +/- ##
=======================================
Coverage ? 45.73%
=======================================
Files ? 831
Lines ? 92172
Branches ? 0
=======================================
Hits ? 42153
Misses ? 43257
Partials ? 6762 Continue to review full report at Codecov.
|
This reverts commit 661d3d2.
* 'main' of https://github.com/go-gitea/gitea: show pull link for agit pull request also (go-gitea#18235) [skip ci] Updated translations via Crowdin Add some .ignore entries (go-gitea#18296) Remove unneeded debug messages to stdout. (go-gitea#18298) Handle missing default branch better in owner/repo/branches page (go-gitea#18290) Revert "Prevent possible XSS when using jQuery (go-gitea#18289)" (go-gitea#18293) not show double error response in git hook (go-gitea#18292) Remove accidental debugging in blob_excerpt.tmpl (go-gitea#18287) Prevent possible XSS when using jQuery (go-gitea#18289) Return nicer error if trying to pull from non-existent user (go-gitea#18288) [skip ci] Updated translations via Crowdin docs: mention client_max_body_size affects LFS (go-gitea#18291) Add lockfile-check (go-gitea#18285) Webauthn nits (go-gitea#18284)
In the case of misuse or misunderstanding from a developer whereby, if `sel` can receive user-controlled data, jQuery `$(sel)` can lead to the creation of a new element. Current usage is using hard-coded selectors in the templates, but nobody prevents that from expanding to user-controlled somehow.
…gitea#18293) This reverts commit 661d3d2.
data-panel
can receive user-controlled data.$(sel)
can lead to the creation of a new element. Current usage is using hard-coded selectors in the templates, but nobody prevents that from expanding to user-controlled somehow.