Does anyone know how to fix the Checkmarx vulnerability -- Cross Site History Manipulation for java based applcations?
Here is the description provided by Checkmarx scan -- "the method may leak server-side conditional values, enabling user tracking from another website. This may constitute a Privacy Violation."
Here is the related code :
if(user is logged in) {
response.sendRedirect(url);
} else {
response.sendRedirect(url)
}
Upon googling I found some Checkmarx documentation which to suggest to add a random number to the redirect url. Here is the link to the document : https://www.checkmarx.com/wp-content/uploads/2012/07/XSHM-Cross-site-history-manipulation.pdf
For e.g :
If ( !isAuthenticated)
Redirect(„Login.aspx?r=‟ + Random())
I tried this approach but the Checkmarx scan still show the same vulnerability.Not sure why.
XSHM could be a CWE-203 (http://cwe.mitre.org/data/definitions/203.html) from CX documentation.
The problem could be complex or simple. With just your 5 lines we can not said exactly what the good solution is.
Checkmarx is check if your redirect url include some random value. Here are some random methods checking by Java/Cx/General/Find_Cross_Site_History_Manipulation_Random:
Random.Next
Math.random
Randomizer.*
Random.nextBytes
Related
The below code is being identified by Fortify as a vulnerability/issue of the "Privacy violation" category.
sbfOut.append(" validateSSN(document.form1." + name
+ ",\" \",\" \")' " + override + "; >");
out.println(sbfOut.toString());
} // SN end
else if (fieldType.equals(CoConstants.DE_ELEMENT_TYPE_TN
In another method I have, Fortify identified the below code block as a vulnerability issue of the "Privacy violation" category as well.
sbfOut.append(" <OPTION VALUE='0'>-NO DATA-</OPTION>");
try {
out.println(sbfOut.toString());
} catch (IOException ioe) {
debug("Exception In coCustomTag" + ioe
I am not able to figure out how to fix this and where exactly the issue is.
The exact message Fortify is giving:
The method methodName() in CoCustomTag.java mishandles confidential information, which can compromise user privacy and is often illegal.
Please ignore the open braces and all, as I have put here only the portion of code identified by Fortify.
If you believe that this issue is a false positive or u can ignore then
Fortify Java Annotations #FortifyNotPassword, #FortifyNotPrivate can be used to indicate which fields and variables represent passwords and private data.
These annotations will tell fortify code analyzer to ignore the fields and issue is gone.
Check below for more details.
HP Fortify -- annotating method parameters
If in your first code snippet HTML output is created and name can be changed by the user (e. g. by rewriting the URL) then this is a cross-site scripting (XSS) vulnerability issue: setting name to ," "," ");alert("Hi");// may cause popping up an alert box.
I was bothered for maybe three days or more, searching Google for any clue I could get, until I looked up into the stack trace on the bottom left of the Audit Workbench (in Fortify). The top of the stack trace suggested to me that my issue was caused by a method named decrypt(...). Believe it or not, when I renamed the method, the issue disappeared.
I am using the Stash's REST API in my project. My task is to get the tag details for a specific tag. After checking the Stash's REST API documentation, I found the correct endpoint that I should be using. It is
/rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/tags/{name:.*}
Please see this link for the Stash's REST API documentation.
There is one more endpoint /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/tags
With this endpoint I am able to retrieve all the tags. The StashTag object looks something like this.
{
"id": "refs/tags/v4.0.0",
"displayId": "v4.0.0",
"latestChangeset": "234dadf41742cfc2a10cadc7c2364438bd8891c5",
"latestCommit": "234dadf41742cfc2a10cadc7c2278658bd8891c5"
"hash" : "null"
}
My first problem is, I don't know which field to use as the parameter for {name:.*}. Should it be the displayId or Id or anything else.
The second problem is, I don't understand what it means to have : (colon) followed by a . (dot) in the endpoint /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/tags/{name:.*}.
Can someone explain me what is the purpose of :. in the path param and how to hit this kind of an endpoint. Also an example of the complete endpoint would be nice.
So far I have tried hitting
https://stashtest.abc.com/rest/api/1.0/projects/KARTIK/repos/kartiks-test-repository/tags/v4.0.0
https://stashtest.abc.com/rest/api/1.0/projects/KARTIK/repos/kartiks-test-repository/tags/refs/tags/v4.0.0
None of these endpoints work.
Any help is appreciated.
The {name:.*} is really just saying that the field name can be anything. Chalk this one up to poor documentation on their part. Think of it like Regex field, because that's exactly what it is. I'm sure at one point they had something like ^[0-9] then went back and changed it when they realized using only tag numbers would omit anyone using their lightweight tag features.
Remove the v from your tag version and see if that helps. If it does not, I would also recommend creating a lightweight tag (something like mytag) and seeing if you can hit it that way (i.e., /kartiks-test-repository/tags/mytag).
But looking at that documentation is telling me that your v in your tag name is throwing off the REST call.
I'm using the JSON API Java library to upload objects to Google Cloud Storage. I've figured out how to add the entity allUsers with role READER to get public access, but any other entity/role entries I try to add to my list of ObjectAccessControl produce some generic errors like
com.google.api.client.googleapis.json.GoogleJsonResponseException: 400 Bad Request
"code" : 400,
"errors" : [ {
"domain" : "global",
"message" : "Invalid Value",
"reason" : "invalid"
}
...for each ACL entry I have, except the allUsers READER one which seems to work
I'm not sure what it's complaining about here. I'm trying to reproduce the default permissions I see in the Developers Console, i.e. when I don't specify any ACL on the metadata.
owners-projectId owner,
editors-projectId owner,
viewers-projectId reader,
and user Id owner (I am guessing this is the service account ID)
I'm adding these to the ACL list the same way as the allUsers entity. I've searched for hours trying to find some documentation or similar issues to this, but only found the one regarding allUsers. I've tried escaping these ids, thinking the JSON library might not be doing so for me, but get the same errors.
Here's my relevant Java code:
// Set permissions and content type on StorageObject metadata
StorageObject objectMetadata = new StorageObject();
// set access control
List<ObjectAccessControl> acl = Lists.newArrayList();
acl.add(new ObjectAccessControl().setEntity("allUsers").setRole("READER"));
// this one allows upload to work without error if it is the only access specified,
// but prevents me from modifying publicly available status or editing permissions
// via the developers console (I think this is to be expected)
// attempt to replicating bucket defaults...
// adding any of these will cause the error
acl.add(new ObjectAccessControl().setEntity("owners-projectId").setRole("OWNER"));
acl.add(new ObjectAccessControl().setEntityId("editors-projectId").setRole("OWNER"));
acl.add(new ObjectAccessControl().setEntityId("viewers-projectId").setRole("READER"));
objectMetadata.setAcl(acl);
where projectId is my project ID copied from the Developer's console site.
Finally figured this out.
I first suspected my storage scope of DEVSTORAGE_READ_WRITE was not sufficient, and tried DEVSTORAGE_FULL_CONTROL, but that was not the reason.
Also ignore my use of setEntityId(...) in my original post, although this was something I also tried to no avail.
The problem was simply incorrect syntax in the entity argument. The document you need is this:
https://cloud.google.com/storage/docs/json_api/v1/defaultObjectAccessControls
Then you will see that the proper method looks something like:
acl.add(new ObjectAccessControl().setEntity("project-owners-projectId").setRole("OWNER"));
Oddly enough, this did NOT work:
acl.add(new ObjectAccessControl().setProjectTeam(new ProjectTeam().setProjectNumber("projectId").setTeam("owners")).setRole("OWNER"));
I suspect that method of setting the project team entity is a bug in the Java library, but I'm not sure.
The error message for incorrect entities that keeps saying Domain global required, or Domain global invalid value, is simply not very instructive. Setting domain is not required for this case. Also see the discussion at:
What domain is Google Cloud Storage expecting in the ACL definitions when inserting an object?
Hope this helps someone else out!
You can set the access control permission by using "predefinedAcl" the code is as follows.
Storage.Objects.Insert insertObject =client.objects().insert(, ,);
insertObject.setPredefinedAcl("publicRead");
This will work fine
I am using Fortify SCA to find the security issues in my application (as a university homework). I have encountered some 'Log Forging' issues which I am not able to get rid off.
Basically, I log some values that come as user input from a web interface:
logger.warn("current id not valid - " + bean.getRecordId()));
and Fortify reports this as a log forging issue, because the getRecordId() returns an user input.
I have followed this article, and I am replacing the 'new line' with space, but the issue is still reported
logger.warn("current id not valid - " + Util.replaceNewLine(bean.getRecordId()));
Can anyone suggest a way to fix this issue?
I know this was already answered, but I thought an example would be nice :)
<?xml version="1.0" encoding="UTF-8"?>
<RulePack xmlns="xmlns://www.fortifysoftware.com/schema/rules">
<RulePackID>D82118B1-BBAE-4047-9066-5FC821E16456</RulePackID>
<SKU>SKU-Validated-Log-Forging</SKU>
<Name><![CDATA[Validated-Log-Forging]]></Name>
<Version>1.0</Version>
<Description><![CDATA[Validated-Log-Forging]]></Description>
<Rules version="3.14">
<RuleDefinitions>
<DataflowCleanseRule formatVersion="3.14" language="java">
<RuleID>DDAB5D73-8CF6-45E0-888C-EEEFBEFF2CD5</RuleID>
<TaintFlags>+VALIDATED_LOG_FORGING</TaintFlags>
<FunctionIdentifier>
<NamespaceName>
<Pattern/>
</NamespaceName>
<ClassName>
<Pattern>Util</Pattern>
</ClassName>
<FunctionName>
<Pattern>replaceNewLine</Pattern>
</FunctionName>
<ApplyTo implements="true" overrides="true" extends="true"/>
</FunctionIdentifier>
<OutArguments>return</OutArguments>
</DataflowCleanseRule>
</RuleDefinitions>
</Rules>
</RulePack>
Alina, I'm actually the author of the article you used to solve your log injection issue. Hope it was helpful.
Vitaly is correct with regards to Fortify. You'll need to build what Fortify calls a "custom rule".
It will likely be a dataflow cleanse rule. A basic example can be found here: http://www.cigital.com/newsletter/2009-11-tips.php. If you own Fortify, there should be a custom rule writing guide in your product documentation.
I don't know what the taint flag you'll use is, but it would look something like "-LOG_FORGING". You would essentially write a rule to remove the log forging "taint" whenever data is passed through your utility method. Fortify will them assume that any data passed through there is now safe to be written to a log, and will not cause log forging.
You need to mark your replaceNewLine as sanitiser in Fortify (if I remember correctly) and it will stop reporting the issue.
You can actually create a new rule from a particular method.
Navigate to the function on the right side of audit workbench after you've done a scan.
Find your sanitizing method and right click on it.
You can generate a rule from it. What you want is a general DataflowCleanseRule.
I just did this based on the xml someone posted above. You can save the rule as a .xml file.
When updating your scan you can pass the -rule argument and point at the .xml file.
I am looking for simple way to connect information about requirement/release and source code.
The case is that developer should be able to find any artifacts created given release or CR in easy way.
The idea I have is to introduce some new annotation to mark any new class ( I am not sure if it is good for any new method) for example:
#ArtifactInfo(release="1.2" cr="cr123")
Do you have any other ideas? Maybe you use already something similar?
Take care,
Marcin
IMO the code is the wrong place for that kind of information.
Take a look at the imaginary code below.
class Authenticator {
login(String username, String password){
User user = retrieveUserFromDatabase(username);
throwIfWrongpassword(user, password);
verifyUserAge(user)
}
void throwIfWrongpassword(User user, String password){
//throws AuthenticationException if password is wrong
}
void verifyUserAge(User user){
//verify that user is above 18 or account is authorized by a parent
}
void biometricLogin(String username, BiometricImage bioimg){
User user = retrieveUserFromDatabase(username);
verifyBiometricImage(user, password);
verifyUserAge(user);
}
}
This is the result of a few requirements:
Users must authenticate to have acces to the system
Users can use biometric authentication instead on password auth
Underaged users must be authorized be parents or something like that.
All those requirements were added in different poins of time, on different versions of the software.
A class-level, or even a method-level annotation won't suffice to effectively map requirements to code.
You'd have to use a "line of code"-level annotation.
Of course, that's impractical.
The right way to do that is to follow a few best practices when using the source code repository and the bug tracker:
1) Every requirement corresponds to one or more issues on the bug tracker
2) Every commit message starts with a corresponding issue key, like "PROJ-123 - a nice feature"
3) When you do a release (meaning, incrementing your software version), you tell the bug tracker that those issues were fixed in that version.
If you need to know what requirements were implemented in what version, ask your bug tracker.
If you need to know all the code that was produced for a given requirement, ask your source code repository (filter commits by log message)
If you need to know what is the requirement for a given line of code, ask your source code repository. GIT and SVN have a "blame" command that will tell you, for a given file, for each line of code, who commited it, when, and the commit message (which will have the issue number if everyone on the team is a good boy) - So this will work as that hypothetical "line-of-code"-level annotation.
Using "commit hooks" can help you enforce rule 2) in an organization.
Maven has some degree of integration with JIRA and other bug trackers, and maybe it can help automate #3. But I haven't really used it like that. But if it doesn't do what you need, you can always ask for more :-)