Purpose
We often use fortify which is a security tool to scan our secruity issue when we prepare to release a new version. This lead us have to fix our issue in a very tense situation, but more important is that some time it is difficult to make a corresponding adjustment at this time because it will affect design or the overall structure.
So I put forward the following two suggestions:
- Every developer need konw the common security rules and abide by the rules.
- We should use the fortify scan every time the code is submitted and should not wait until the end.
Overview
This is topic we need offen update, because security issues are constantly changing, here I summarize what we often encounter.
Issue For Exception
- Empty catch block. The exception will be ignored. Bad case:
catch (final JaloItemNotFoundException e) {
}
|
- We can not directly catch base exception, we should add more type of exception to handle error. Bad case:
catch (final Exception e) {
}
|
- We should not direct print the details info of the Exception Object in catch, we shoud wrap the exception. Bad case:
catch (final Exception e) {
log.error(e);
}
|
InitBinder
The initBinder is a check for the form submit. We can set the AllowedFields and DisallowedFields to filter the form submit. But actually, we already have the check of the form submit in the frontend. We set the DisallowedFields to be empty, to allow all the form submit fileds.
@InitBinder
public void initBinder(WebDataBinderbinder) {
binder.setDisallowedFields(DISALLOWED_FIELDS);
}
|
CSRF
When the form labels are used, it is better to use the form label which Spring offers, do not use form labels directly. It will support csrf validation.
<%@ page trimDirectiveWhitespaces="true"%>
<%@ taglib prefix="template" tagdir="/WEB-INF/tags/responsive/template"%>
<%@ taglib prefix="formElement" tagdir="/WEB-INF/tags/responsive/formElement"%>
<div class="account-section-header">
<div class="row">
<div class="container-lg col-md-6">
<spring:theme
code="text.account.notificationPreference.notificationPreferenceForm" />
</div>
</div>
</div>
<div class="row">
<div class="container-lg col-md-6">
<div class="account-section-content">
<div class="account-section-form">
<form:form action="${action}" method="post"
commandName="notificationPreferenceForm">
<c:forTokens var="channel" items="email,sms" delims="," varStatus="loop">
<div class="checkbox">
<label class="control-label notification_preference_channel">
<c:if test="${not empty notificationPreferenceForm.emailAddress && channel == 'email'}">
<form:checkbox idKey="${channel}NotificationChannel" path="${channel}Enabled"tabindex="${loop.index}"/>
<span><spring:theme code="notification.channel.${channel}"arguments="${notificationPreferenceForm.emailAddress}"/></span>
</c:if>
<c:if test="${not empty notificationPreferenceForm.mobileNumber && channel == 'sms'}">
<form:checkbox idKey="${channel}NotificationChannel" path="${channel}Enabled"tabindex="${loop.index}"/>
<span><spring:theme code="notification.channel.${channel}"arguments="${notificationPreferenceForm.mobileNumber}"/></span>
</c:if>
</label>
</div>
</c:forTokens>
<div class="row">
<div class="col-sm-6 col-sm-push-6">
<div class="accountActions">
<button type="submit" class="btn btn-primary btn-block">
<spring:theme code="notificationPreferenceSetting.submit" text="Update Password" />
</button>
</div>
</div>
<div class="col-sm-6 col-sm-pull-6">
<div class="accountActions">
<button type="button" class="btn btn-default btn-block backToHome">
<spring:theme code="notificationPreferenceSetting.cancel" text="Cancel" />
</button>
</div>
</div>
</div>
</form:form>
</div>
</div>
</div>
</div>
|
Weak Cryptographic Hash
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts. We should use sha256 or at the same level.
This case is not safe enough:
DigestUtils.md5Hex(preStr);
|
Mass Assignment: Insecure Binder Configuration
The framework binder used for binding the HTTP request parameters to the model class has not been explicitly configured to allow, or disallow certain attributes.
@RequestMapping(method = RequestMethod.POST)
@RequireHardLogIn
public String updateNotificationPreference(final NotificationPreferenceForm notificationPreferenceForm,
final BindingResult bindingResult, final Model model, final RedirectAttributes redirectModel)
|
Open Redirect
The file MyInterestsPageController.java passes unvalidated data to an HTTP redirect function on line 115. Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.
final String showUrl = getConfigurationService().getConfiguration().getString(urlKey) + "/" + productCode;
return "redirect:" + showUrl;
|
The method post() in WeChatPayHttpClient.java includes unvalidated data in an HTTP response header on line 69. This enables attacks such as cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.
WeChatPayHttpClient
post.setEntity(new StringEntity(requestBody, ContentType.create(MediaType.APPLICATION_XML.toString(), CharEncoding.UTF_8)));
|
Hidden field
sing the input hidden to save variable in jsp files. The variable will be exposed.
<input type="hidden" name="${var.key}" value="${var.value}" />
<input name="${var.key}" value="${var.value}" readonly style="display: none;"/>
|
Java Details
- Parse Double, use this case
- StringUtils.EMPTY, use this case
String temp = StringUtils.EMPTY;
|
