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.

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

Trust Boundary Violation test cases are not exploitable #43

Open
thornmaker opened this issue Nov 7, 2017 · 12 comments
Open

Trust Boundary Violation test cases are not exploitable #43

thornmaker opened this issue Nov 7, 2017 · 12 comments

Comments

@thornmaker
Copy link

It is my understanding that test cases are to be fully executable and exploitable. Trust Boundary Violation issues do not appear to meet this baseline as they are not exploitable. As such, I'm requesting that this category of issues be removed. Please find below supporting evidence.

According to CWE-501 - Trust Boundary Violation the negative consequence of a Trust Boundary Violation is that "it becomes easier for programmers to mistakenly trust unvalidated data". Should a developer mistakenly trust the unvalidated in some other part of the application, then this certainly could lead to an exploitable scenario. However, "combining trusted and untrusted data in the same data structure" alone is not something actionable by an attacker and thus not exploitable.

The OWASP website itself has essentially no meaningful information on this issue.

I could not identify any CVEs associated to Trust Boundary Violations. For example, a CVE search for such issues returns 0 results.

@davewichers
Copy link
Contributor

davewichers commented Nov 10, 2017 via email

@jmanico
Copy link

jmanico commented Nov 10, 2017 via email

@thornmaker
Copy link
Author

thornmaker commented Nov 19, 2017

What do you think about this idea?

I have no qualms about revamping the categories. More importantly though, I would like to see more diversity in test cases beyond just [source] + [dataflow pattern] + [sink]. This is getting a bit off-topic for this issue though.

For Trust Boundary Violation issues, it seems there is agreement (at least between those who have commented) that this category should be dropped.

@dbolkensteyn
Copy link

👍 on dropping the trust boundary examples and category.

Also, it is not obvious to me that CWE-501 is about preventing unescaped user-data from being stored in sessions, which seems to be the focus of the benchmark examples. The description mentions that mixing of trusted & untrusted data is the issue. So, if some of the keys are HTML-escaped, but some others are not, then there is an issue. Specifically on sessions, I actually tend to think that storing HTML-escaped data there is a bad practice as it does not preserve the original data and makes it specific for a single purpose (HTML) and no longer enables the data to be saved to a DB for example. Instead, I would prefer to consider session data as sources for the other vulnerabilities such as (stored-?)XSS.

@DomKoe
Copy link

DomKoe commented Aug 12, 2020

From my understanding the issue with the Trust Boundary Violation test cases remains?

@davewichers
Copy link
Contributor

Yes. That is simply because the project has not released v1.3, which will drop those test cases. So for now, ignore them if you do not care about them.

@DomKoe
Copy link

DomKoe commented Aug 13, 2020

Thank you for your answer. What would be the next milestones for v1.3? I have written you on Slack as well, with further questions.

@bmuskalla
Copy link

bmuskalla commented Jul 21, 2021

That is simply because the project has not released v1.3, which will drop those test cases

@davewichers Do you happen to have a timeline for this? Just stumbled over those tests as well with the same questions @DomKoe had. No pressure, mostly curious :)

@davewichers
Copy link
Contributor

davewichers commented Jul 21, 2021

@bmuskalla - Release v1.3 is basically ready, but going through some QA. My son @JonathonWichers is actually helping me get this done. I hope to have it out in a few months.
@DomKoe - You mentioned sending me questions in slack, but I don't really pay attention to any OWASP slack channel. Feel free to email me directly at: dave.wichers@owasp.org.

@bmuskalla
Copy link

bmuskalla commented Jul 21, 2021

@davewichers I assume 1.3 is being worked on in private as I don't see any branches or references to it on main? Or is there something in public we can check out in the meantime? And thanks for the fast feedback :)

@davewichers
Copy link
Contributor

@bmuskalla - That's correct. Its private currently, but I've been thinking about changing that. My idea is to create a v1.3 dev branch and push it out as a preview/release candidate. And I'd periodically update it based in improvements/addressing feedback, until its ready for release, then I'd merge it in.

I'm also doing some significant surgery on the Generator, because it's really 3 apps in one: test case generator, the web app the test cases go into, and the scoring machinery. And then the Benchmark itself is a subset of the Generator (the web app part, plus the generated test case, plus the scoring app), but without the generation engine and the configuration/code snippets used to generate the Benchmark.

I'd like to release the Scoring engine as a separate app. That way, when multiple versions of Benchmark (Java, dotNet, etc.) come out, all of them could use the separate standalone scoring engine to generate scorecards. (There is an OWASP team working (slowly) on Benchmark dotNet, by the way, in case anyone wants to help them.) If so, just let me know.

@bmuskalla
Copy link

Thanks for the overview of the ongoing work, looking forward to it.

That's correct. Its private currently, but I've been thinking about changing that. My idea is to create a v1.3 dev branch and push it out as a preview/release candidate

That would be awesome for people to try it out early and give feedback before the merge. Just give me a nudge here and I'll give it a try running it against CodeQL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants