-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Server-Side Template Injection (SSTI) False Positive #8622
Comments
Please, provide all the details of the alert. |
@thc202 I provided the context of the alert detection |
We are after the full details of the alert. |
@kingthorin OK, I added the full json report with request and response |
Thanks that helps. |
@kingthorin if you can delete the data and we share the information privately I appreciate. |
No problem. Removed. I can store in a limited access location. |
@kingthorin did you have the chance to look on the issue? |
I think I might see an issue based on what you'd shared. I need to dig into the code. |
@kingthorin Have you been able to identify the issue, or would you like more details? |
Thanks for checking in. Unfortunately due to an injury I haven't been able to dig into it yet. |
Oh, sorry to hear that, I hope you get better |
Hey @kingthorin, sorry to hear about your injury. I hope you get feeling better soon! Also, congratulations on the Checkmarx move :) I'm chiming in here with more data to help elucidate what I think is going on. With our clients, it appears that about 80% of the SSTI findings come from one particular check: the GoTemplateFormat. The GoTemplateFormat checks for a concatenation of two numbers instead of a math operation like other template tests. It appears to generate FPs far more frequently due to how web apps tend to place input parameters into the page while filtering special characters. For example, here's the first 3 SSTI alerts I looked at from different sites: Attack: Attack Attack The pattern is consistently that the attack parameter gets stripped of special characters and inserted into the page or URL. Since stripping the attack of special characters results in the concatenation of the two numbers, the test for concatenation doesn't differentiate between a correctly discovered evaluation of the attack parameter and an FP of the parameter getting cleaned and put back on the page without evaluation. This definitely could be poor input parameter handling by the site, but I don't believe clears the threshold for SSTI. I didn't dig into the history of the GoTemplateFormat to figure out why concatenation was used instead of multiplication like most of the others. Let me know if you want me to add the full software version info or help contribute in some way. |
Thanks that's great. The details are highly appreciated |
Took a look at the PR, looks great. Thanks a ton for all you do @kingthorin |
Describe the bug
A Server-Side Template Injection (SSTI) vulnerability has been detected in the web application, but not the way I expected.
I ran on AttackStrength Default and HIGH, both got on this scenario.
This is happening on a variety of scan on different domains (+40)
How I can mitigate this False Positive?
Why does the scan looks only for the value
40034618
and not the entirezjprint40034618zj
?Steps to reproduce the behavior
Go to the following URL: [https://XXX.com/wp-login.php?action=bpnoaccess&bp-auth=1&redirect_to=https%3A%2F%2FXXX.ocm%2Fmembers%2Fadmin-wa%2F&wp_lang=zj%7B%7Bprint+%222712%22+%223997%22%7D%7Dzj]
The response
Expected behavior
I expected this is not a vulnerability. I had quite a lot of a false positive where the lang has the value with the print in it.
Software versions
Current stable and dev versions was used for this.
Screenshots
No response
Errors from the zap.log file
No response
Additional context
Report:
Would you like to help fix this issue?
The text was updated successfully, but these errors were encountered: