Develop Reference

TAINTED_SOURCE - os_command_sink

Further to Tainted_source JAVA, I want to add more information regarding the error os_command_sink I am getting.
Below is the section of code that's entry point of data from front end and marks parameter as tainted_souce
Now when the DTO - CssEmailWithAttachment is sent to static method of CommandUtils, it reports os_command_sink issue. Below is the code for the method
I tried various ways to sanitize the source in controller method - referenceDataExport i.e. using allowlist, using #Pattern annotation but coverity reports os_command_sink all the times.
I understand the reason as any data coming from http is marked as tainted by default. And the code is using the data to construct an OS command hence the issue is reported.
Coverity provides below information regarding the issue
So I tried strict validation of entityType that it should be one of the known values only but that also doesn't remove the issue.
Is there anyway this can be resolved?
Thanks

The main issue is that the code, as it currently stands, is insecure. To summarize the Coverity report:
entityType comes from an HTTP parameter, hence is under attacker control.
entityType is concatenated into tagline.
tagline is passed as the body and subject of CdsEmailWithAttachment. (You haven't included the constructor of that class, so this is partially speculation on my part.)
The subject and body are concatenated into an sh command line. Consequently, anyone who can invoke your HTTP service can execute arbitrary command lines on your server backend!
There is an attempt at validation in sendEmailWithAttachment, where certain shell metacharacters are filtered out. However, the filtering is incomplete (missing at least single and double quote) and is not applied to the subject.
So, your first task here is to fix the vulnerability. The Coverity tool has correctly reported that there is a problem, but making Coverity happy is not the goal, and even if it stops reporting after you make a change, that does not necessarily mean the vulnerability is fixed.
There are at least two straightforward ways I see to fix this code:
Use a whitelist filter on entityType, rejecting the request if the value is not among a fixed list of safe strings. You mentioned trying the #Pattern annotation, and that could work if used correctly. Be sure to test that your filter works and provides a sensible error message.
Instead of invoking mailx via sh, invoke it directly using ProcessBuilder. This way you can safely transport arbitrary data into mailx without the risks of a shell command line.
Personally, I would do both of these. It appears that entityType is meant to be one of a fixed set of values, so should be validated regardless of any vulnerability potential; and using sh is both risky from a security perspective and makes controlling the underlying process difficult (e.g., implementing a timeout).
Whatever you decide to do, test the fix. In fact, I recommend first (before changing the code) demonstrating that the code is vulnerable by constructing an exploit, as that will be needed later to test any fix, and is a valuable exercise in its own right. When you think you have fixed the problem, write more tests to really be sure. Think like an attacker; be devious!
Finally, I suspect you may be inexperienced at dealing with potential security vulnerabilities (I apologize if I'm mistaken). If so, please understand that code security is very important, and getting it right is difficult. If you have the option, I recommend consulting with someone in your organization who has more experience with this topic. Do not rely only on Coverity.

Creating Exception sub-class for handling business logic errors or using error codes? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am using Java and I would like to find out the pros and cons of creating Exception sub-class to throw biz exceptions or should I be using error codes to handle biz exception?
Let's take a typical banking application for example, there are several exception when a transfer of funds would go wrong. i.e Insufficient Fund, Invalid Target Account, Exceed the maximum transfer limit for the day.
Should I create a list of error codes to return to the caller? or should I be throwing Exception class (inherit from Exception) to the caller?
If I were to create Exception for every biz exception, there could possibly be a lot of Exception classes.

You could use Exception class all the way to throw your exceptions with specific message and even could send out error codes.
But you business logic should decide it whether you want to create an exception or go with error codes.
With custom exceptions comes a great advantage i.e. you could define hierarchy. For your example of banking application, we know that if there comes Insufficient Fund, Invalid Target Account, Exceed the maximum transfer limit for the day situations, then all these are at first TransactionFailures due to some reason. Hence your exception hierarchy could be like below:
TransactionFailureException
/ \
/ \
/ \
/ \
InsufficientFundException / InvalidTargetAccountException / MaxLimitReachedException
Hence exception handling provided you with a standard business logic level error hierarchy which is understood by everyone and hence is helpful is setting up standard.
But error code are also very important as these specify a specific problem just by code number.
Would recommend using both for best robust application.

Using error codes would lead to:
call the function and return error codes
then handle the error codes in an if-else-cascade
and in each conditional block recover the context
and then recover the function
In this case exceptions could help a lot:
you will not have to return an error code, you can use the return value for more meaningful results
you will not have to handle errors in an if-else-cascade but with a try-catch-cascade (which is better for the reader to see that somethin is recovered)
you will not have to recover the context, because the exception could hold the necessary context information (if designed correctly)
If error codes are just a throw-aways that are ignored and not recovered one simple exception type holding an error code would be sufficient.

The big advantage of exception handling is that it keeps your code cleaner. The code looks like a sequenece if actions without too many if statements, so that the main use case is apparent from the source code.
In Java, the compiler also helps because it forces you to declare the types of exceptions that a function may throw.
Now, if you have many different reasons for failure, you don't necessarily need to create a separate exception class for each reason. They could share the same exception type, with an enum inside of it providing more specific information. Or you may create separate exception classes and have each of them inherit from the same base exception. If the logic of handling the exception is the same for all of them, you need to catch the base exception.

You can use both together for a robust error handling and logging purpose.
Create a predefined list of error codes and respective error descriptions and let those store some persistence storage. Each time your application starts up, you load the same in a Map. Storing in persistence storage will have two benefits:
a. Scalability: If you have a very large set of error codes, it is good to store those in table instead of hard coding those in code.
b. Maintainability: Maintenance will be easy. No need to modify your code each time there are some changes in your error code or error description. Also adding any new error code is easy. For example, one single insert query is sufficient in your error code table for a new error code.
Create custom business exceptions based on the the business category (For example, one category could be InvalidAccountInformation, another category could be InvalidTransaction and so on). You can pass your custom error code in these custom business exceptions. You can fetch the custom error description with the error code and log accordingly. A good idea would be your custom exceptions should be subclass of RuntimeException class.

Best practice on exception and error handling with Selenium and SerenityBDD (thucydides)

Actually I'm writing a bunch of tests but I'm not sure how I should handle exceptions/errors best.
There a different types of exceptions, e.g. AssertException if a result was not as expected using assertThat(..). This is O.K. and understandable.
But what if I have a FileNotFound / SOAPException / DOMException and so on...?
For example in my #BeforeStory method I create some testdata by reading testfiles and sending them to a webservice and there I could possibly get the above mentioned exceptions. I would like to present these errors by using an own error message also in the living documentation. But how should I manage this? Actually I'm thinking about two approaches:
1.) I catch the exception and throw my own new exception with an individual error message. The testexecution is aborted for the scenario and the exception is presented in the living documentation.
2.) I catch the exception, implement a string based return statement with the error message and use an assertThat(...) in my low-level specifications so I only should get AssertException in the end.
3.) ..?
Question: And advice or common best practices how to handle exceptions or errors with selenium/serenity ?

First of all, there is a good source of information for you theme - xUnit test patterns book.
Answering your question, the good approach is using 2 major groups of errors. The first one is AssertionException indicating a problem (bug) in application under test. The second one are all other exceptions indicating problems in test code itself, test execution env or application env, but not in application. Building your tests this way will help you finding and eliminating problems fast.
So generally you are on the right way with your first option. It's a good idea to collect some additional data (e.g. application/execution env) when exception occurs as well.

How to stop ANTLR from suppressing syntax errors?

So I'm writing a compiler in Java using ANTLR, and I'm a little puzzled by how it deals with errors.
The default behavior seems to be to print an error message and then attempt, by means of token insertion and such, to recover from the error and continue parsing. I like this in principle; it means that (in the best case) if the user has committed more than one syntax error, they'll get one message per error, but it'll mention all the errors instead of forcing them to recompile to discover the next one. The default error message is fine for my purposes. The trouble comes when it's done reading all the tokens.
I am, of course, using ANTLR's tree constructors to build abstract syntax trees. While it's nice for the parse to continue through syntax errors so the user can see all the errors, once it's done parsing I want to get an exception or some kind of indication that the input wasn't syntactically valid; that way I can stop the compilation and tell the user "sorry, fix your syntax errors and then try again". What I don't want is for it to spit out an incomplete AST based on what it thinks the user was trying to say, and continue to the next phase of compilation with no indication that anything went wrong (other than the error messages which went to the console and I can't see). Yet by default, it does exactly that.
The Definitive ANTLR Reference offers a technique to stop parsing as soon as a syntax error is detected: override the mismatch and recoverFromMismatchedSet methods to throw RecognitionExceptions, and add a #rulecatch action to do the same. This would seem to lose the benefit of recovering from parse errors, but more importantly, it only partially works. If a necessary token is missing (for instance, if a binary operator only has an expression on one side of it), it throws an exception just as expected, but if an extraneous token is added, ANTLR inserts the token that it thinks belongs there and continues on its merry way, producing an AST with no indication of a syntax error except a console message. (To make matters worse, the token it inserted was EOF, so the rest of the file didn't even get parsed.)
I'm sure I could fix this by, say, adding something like an isValid field to the parser and overriding methods and adding actions so that, at the end of the parse, it throws an exception if there were any errors. But is there a better way? I can't imagine that what I'm trying to do is unusual among ANTLR users.

... [O]nce it's done parsing I want to get an exception or some kind of indication that the input wasn't syntactically valid; that way I can stop the compilation...
You can call getNumberOfSyntaxErrors on both the lexer and the parser after parsing to determine if there was an error that was covertly accommodated by ANTLR. This doesn't tell you what those errors were, obviously, but I think these methods address the "once it's done parsing ... stop the compilation" part of your question.
The Definitive ANTLR Reference offers a technique to stop parsing as soon as a syntax error is detected: override the mismatch and recoverFromMismatchedSet methods to throw RecognitionExceptions, and add a #rulecatch action to do the same.
I don't think you mentioned which version of ANTLR you're using, but the documentation in the ANTLR v3.4 code for the method recoverFromMismatchedSet says it's "not currently used" and an Eclipse "global usage" scan found no callers. Neither here nor there to your main problem, but I wanted to mention it for the record. It may be the correct method to override for your version.
If a necessary token is missing ..., [the overridden code] throws an exception just as expected, but if an extraneous token is added, ANTLR inserts the token that it thinks belongs there and continues on its merry way...
Method recoverFromMismatchedToken tests for a recoverable missing and extraneous token by delegating to methods mismatchIsMissingToken and mismatchIsUnwantedToken respectively. If the appropriate method determines that an insertion or deletion will solve the problem, recoverFromMismatchedToken makes the appropriate correction. If it is determined that no operation solves the mismatched token problem, recoverFromMismatchedToken throws a MismatchedTokenException.
If a recovery operation takes place, reportError is called, which calls displayRecognitionError with the details.
This applies to ANTLR v3.4 and possibly earlier versions.
This gives you at least two options:
Override recoverFromMismatchedToken and handle errors at a fine-grained level. From here you can delegate the call to the super implementation, roll your own recovery code, or bail out with an exception. Whatever the case, your code will be called and thus will be aware that a mismatch error occurred, recoverable or otherwise. This option is probably equivalent to overriding recoverFromMismatchedSet.
Override displayRecognitionError and handle the errors at a course-grained level. Method reportError does some state juggling, so I wouldn't recommend overriding it unless the overriding implementation calls the super-implementation. Method displayRecognitionError appears to be one of the last calls in the recovered-token call chain, so it would be a reasonable place to determine whether or not to continue. I would prefer it had a name that indicated that it was a reasonable place for that, but oh well. Here is an answer that demonstrates this option.
I'm partial towards overriding displayRecognitionError because it provides the error message text easily enough and because I know it's going to be called only after a token recovery operation and required state juggling -- no need for my parser to figure out how to recover for itself. This coupled with getNumberOfSyntaxErrors appear to give you the options that you're looking for, assuming that you're working with a relevant version of ANTLR and that I fully understood your problem.

How can I provide custom error messages using JAXP DocumentBuilder?

I want to provide my own message from the validation done in DocumentBuilder, rather than the one from XMLMessages.properties.
Now I see that a property error-reporter needs to be set to a class which extends XMLErrorReporter.
However, I've not been able to get ComponentManager from Document/Builder/Factory.
Doing parsing of string in SAXParseException is the last option, but I'm just thinking there may be a 'best practice' way of doing it.

have you already looked at DocumentBuilder#setErrorHandler?
if yes, could you explain why this approach doesn't work for you?