Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Possibility of Reflected Cross-Site Scripting (XSS) attack is detected by static code analysis #1476

Closed
visheshtanksale opened this issue Dec 6, 2024 · 2 comments
Closed

Possibility of Reflected Cross-Site Scripting (XSS) attack is detected by static code analysis #1476

visheshtanksale opened this issue Dec 6, 2024 · 2 comments

Comments

@visheshtanksale
Copy link

Describe the bug
The attacker would be able to alter the returned web page by simply providing modified data in the user input Body, which is read by the decodePutRequest method here. This input then flows through the code straight to the output web page, without sanitization.

To Reproduce
Steps to reproduce the behavior

Expected behavior
The input should be validated

Additional context
Add any other context about the problem here.
abhinav added a commit that referenced this issue Dec 7, 2024
@abhinav
test(AtomicLevel): demonstrate Handler is not vulnerable to XSS
3a7b092 
Adds a unit test and a fuzz test to demonstrate
that the AtomicLevel handler is not vulnerable to XSS.

I ran the fuzz test on my computer for 10 minutes on my laptop
with no cases where `<...>` was present in the response body.

```
...
fuzz: elapsed: 9m57s, execs: 43145040 (95839/sec), new interesting: 442 (total: 445)
fuzz: elapsed: 10m0s, execs: 43396113 (83690/sec), new interesting: 442 (total: 445)
```

Resolves #1476
@abhinav abhinav mentioned this issue Dec 7, 2024
Merged
@abhinav
Copy link
Collaborator

abhinav commented Dec 7, 2024

Thanks for reporting, @visheshtanksale. I believe that this is a false positive in the static analysis tool.

decodePutRequest decodes the JSON blob. It produces a level out to the response body if and only if it's a recognized level. All other values result in error. The original input is reproduced to the user only with escaping (e.g. encoding/json's HTML escaper).

I do not believe it's possible to produce arbitrary HTML on the page through this means.
I've put up PR #1477 to demonstrate this.

If you think this is incorrect, please provide more details on how to reproduce this.

abhinav added a commit that referenced this issue Dec 10, 2024
@abhinav
test(AtomicLevel): demonstrate Handler is not vulnerable to XSS (#1477)
5f00c34 
Adds a unit test and a fuzz test to demonstrate
that the AtomicLevel handler is not vulnerable to XSS.

I ran the fuzz test on my computer for 10 minutes on my laptop
with no cases where `<...>` was present in the response body.

```
...
fuzz: elapsed: 9m57s, execs: 43145040 (95839/sec), new interesting: 442 (total: 445)
fuzz: elapsed: 10m0s, execs: 43396113 (83690/sec), new interesting: 442 (total: 445)
```

Refs #1476
@sywhang
Copy link
Contributor

sywhang commented Dec 10, 2024

Closing this issue as demonstrated by #1477. Please feel free to reopen if you disagree.

@sywhang sywhang closed this as completed Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@abhinav @visheshtanksale @sywhang