39 lines
1.7 KiB
Plaintext
39 lines
1.7 KiB
Plaintext
=== on 23 Jul 2015, 07:15:31 Nicolas Peru wrote:
|
|
Not sure if it should be part of the description but it is not really clear if the rule is limited to the API in the example.
|
|
|
|
=== on 23 Jul 2015, 09:05:19 Ann Campbell wrote:
|
|
FYI [~tamas.vajk]
|
|
|
|
=== on 19 Apr 2018, 10:53:30 Alexandre Gigleux wrote:
|
|
This is a "Security Weakness".
|
|
|
|
=== on 4 Sep 2018, 10:28:09 Alexandre Gigleux wrote:
|
|
\[~nicolas.harraudeau] Review
|
|
|
|
I think you should ask yourself if this rule is only relevant for Java. If this is the case, it is no longer a Common Security Hotspot rule.
|
|
|
|
Check if C#, VB.Net are really excluded, I don't think so. Also I believe PHP, Swift, Scala, Kotlin, Ruby should be in the list of Targeted Languages.
|
|
|
|
|
|
|
|
=== on 4 Sep 2018, 11:29:31 Nicolas Harraudeau wrote:
|
|
\[~alexandre.gigleux] Thanks for the review
|
|
|
|
Here are examples for the targeted languages: \https://rosettacode.org/wiki/Break_OO_privacy
|
|
|
|
Ruby is a special case.
|
|
|
|
=== on 6 Apr 2020, 12:01:04 Eric Therond wrote:
|
|
Altering accessibility at run-time is not possible if a security manager is configured (in Java) or the code doesn't have the right permission (https://docs.microsoft.com/fr-fr/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection[in C#]).
|
|
|
|
|
|
So a new security-hotspot rule could be relevant in the future to detect when a loose permission is granted that allow, for instance, external code to change accessibility of fields of a trusted code and thus access to private information, however here:
|
|
|
|
* The rule raises when the accessibility is changed, so basically "the consequence" and not the root cause of the bug is highlighted.
|
|
* Reflection will be most of the times used to create dynamic types or to perform debugging.
|
|
|
|
So a code smell is more appropriate than a security rule.
|
|
|
|
|
|
|