Java: Big Decimal DOS #6730
Java: Big Decimal DOS #6730
Conversation
java/ql/src/experimental/Security/BigDecimalDOS/BigDecimalDOS.ql
Outdated
Show resolved
Hide resolved
| override predicate isSource(DataFlow::Node src) { src instanceof RemoteFlowSource } | ||
|
|
||
| override predicate isSink(DataFlow::Node sink) { | ||
| exists(Method method, MethodAccess call | |
There was a problem hiding this comment.
Thanks @atorralba for helping review this part of the code.
Yes, I will do more tests and add these methods!
java/ql/src/experimental/Security/BigDecimalDOS/BigDecimalDOS.qhelp
Outdated
Show resolved
Hide resolved
|
|
||
|
|
||
| <overview> | ||
| <p>Directly incorporating user input into an BigDecimal Operation Function without validating the input |
There was a problem hiding this comment.
Should probably use the term "method" instead of "function" since that is the commonly used term in the Java context.
(And also a few lines below the term "method" is used as well)
| <recommendation> | ||
|
|
||
| <p>To guard against BigDecimal DOS attacks, you should avoid putting user-provided input | ||
| directly into a BigDecimal Method(like: add(), subtract()). Instead, In some e-commerce payment scenarios, |
There was a problem hiding this comment.
| directly into a BigDecimal Method(like: add(), subtract()). Instead, In some e-commerce payment scenarios, | |
| directly into a BigDecimal method (like: add(), subtract()). Instead, in some e-commerce payment scenarios, |
Maybe it would also be worth formatting these methods as code using <code>...</code>?
There was a problem hiding this comment.
Thanks @Marcono1234 help review, I will to do some modify about this query rule's help file.
java/ql/src/experimental/Security/BigDecimalDOS/BigDecimalDOS.qhelp
Outdated
Show resolved
Hide resolved
java/ql/src/experimental/Security/BigDecimalDOS/BigDecimalDOS.qhelp
Outdated
Show resolved
Hide resolved
| @@ -0,0 +1,38 @@ | |||
| /** | |||
| * @id java/BigDecimalDOS | |||
| * @name Java-BigDecimal-DOS-Vulnerability | |||
There was a problem hiding this comment.
The name does not have to use hyphens, see query metadata style guide
java/ql/src/experimental/Security/BigDecimalDOS/BigDecimalDOS.ql
Outdated
Show resolved
Hide resolved
java/ql/src/experimental/Security/BigDecimalDOS/BigDecimalDOS.ql
Outdated
Show resolved
Hide resolved
| @ResponseBody | ||
| // GOOD: | ||
| public Long demo02(@RequestParam(name = "num") String num) { | ||
| if (num.length() > 33 || num.matches("(?i)e")) { |
There was a problem hiding this comment.
Shouldn't that be:
| if (num.length() > 33 || num.matches("(?i)e")) { | |
| if (num.length() > 33 || num.matches("(?i).*e.*")) { |
(or similar)
| } | ||
| Long startTime = System.currentTimeMillis(); | ||
| BigDecimal num1 = new BigDecimal(0.005); | ||
| System.out.println(num1.add(num)); |
There was a problem hiding this comment.
There is no BigDecimal.add(String); you would probably have to convert num it to a BigDecimal first
Co-authored-by: Tony Torralba <[email protected]>
Co-authored-by: Marcono1234 <[email protected]>
Co-authored-by: Marcono1234 <[email protected]>
Co-authored-by: Marcono1234 <[email protected]>
Co-authored-by: Marcono1234 <[email protected]>
Co-authored-by: Marcono1234 <[email protected]>
|
Note that tests are failing: |
Directly incorporating user input into an BigDecimal Operation Function without validating the input
can facilitate DOS attacks. In these attacks, the server
will consume a lot of computing resources, A typical scenario is that the CPU usage rises to close to 100%.
This issue often occurs in scenarios that require scientific computing, such as e-commerce platforms and electronic payments.