浅谈Java开发中的安全编码问题
1-输入校验
编码原则：针对各种语言本身的保留字符，做到数据与代码相分离。
1.1SQL注入防范
严重性高，可能性低。
(1)参数校验，拦截非法参数（推荐白名单）：
publicStringsanitizeUser(Stringusername){
returnPattern.matches("[A-Za-z0-9_]+",username)
?username:"unauthorizeduser";
}
(2)使用预编译：
Stringsql="UPDATEEMPLOYEESSETSALARY=?WHEREID=?"; PreparedStatementstatement=conn.prepareStatement(sql); statement.setBigDecimal(1,285500.00); statement.setInt(2,30015800);
1.2XSS防范
严重性中，可能性高。防范方法有：
(1)输入输出校验（推荐白名单）；
(2)org.apache.commons.lang工具包处理；
(3)富文本可用owaspantisamp或javahtmlsanitizer处理；
(4)ESAPI处理：
//HTML实体 ESAPI.encoder().encodeForHTML(data); //HTML属性 ESAPI.encoder().encodeForHTMLAttribute(data); //JavaScript ESAPI.encoder().encodeForJavaSceipt(data); //CSS ESAPI.encoder().encodeForCSS(data); //URL ESAPI.encoder().encodeForURL(data);
1.3代码注入/命令执行防范
严重性高，可能性低。
(1)参数校验，拦截非法参数（推荐白名单）；
(2)不直接执行用户传入参数：
if("open".equals(request.getParameter("choice"))){
Runtime.getRuntime().exec("yourcommand...");
}
(3)及时更新升级第三方组件：
比如Struts、Spring、ImageMagick等。
1.4日志伪造防范
严重性低，可能性高。
(1)不要log用户可控的信息；
(2)输入参数校验（推荐白名单）：
//处理回车、换行符
Patternp=Pattern.compile("%0a|%0d0a|\n|\r\n");
Matcherm=p.matcher(data);
dest=m.replaceAll("");
(3)使用Log4j2。
1.5XML外部实体攻击
严重性中，可能性中。
(1)关闭内联DTD解析，使用白名单来控制允许使用的协议；
(2)禁用外部实体：
DocumentBuilderFactoryfactory=DocumentBuilderFactory.newInstance();
factory.setExpandEntityReferences(false);
(3)过滤用户提交的XML数据：
比如!DOCTYPE、
1.6XML注入防范
严重性中，可能性低。
(1)教研用户输入（推荐白名单）：
OutputFormatformat=OutputFormat.createPrettyPrint();
(2)使用安全的XML库（比如dom4j）。
1.7URL重定向防范
严重性中，可能性低。
(1)设置严格白名单几网络边界：
Stringurl=request.getParameter("url");
Stringhost=getHostFromUrl(url);
if(!validateHost(host)){
return;
}
(2)加入有效性验证的Token；
(3)referer适用于检测监控URL重定向、CSRF等，多数场景下也可用作防范措施。
2-异常处理
编码原则：不要泄露详细异常信息。
2.1敏感信息泄露防范
严重性低，可能性中。
屏蔽敏感信息示例：
catch(IOExceptione){
System.out.println("Invalidfile");
//System.out.println("Errorcode:0001");
return;
}
2.2保持对象一致性
严重性中，可能性低。
(1)重排逻辑，使得产生异常的代码在改变对象状态的代码之前执行；
catch(Exceptione){
//revert
money-=PADDING;
return-1;
}
(2)在出现异常导致操作失败的情况下，使用事务回滚机制；
(3)在对象的临时拷贝上执行操作，成功后再提交给正式的对象；
(4)回避修改对象的需求，尽量不去修改对象。
3-I/O操作
编码规则：可写的文件不可执行，可执行的文件不可写。
3.1资源释放
严重性低，可能性高。
Java垃圾回收器回自动释放内存资源，非内存资源需要开发人员手动释放，比如DataBase，Files，Sockets，Streams，Synchronization等资源的释放。
try{
Connectionconn=getConnection();
Statementstatement=conn.createStatement();
ResultSetresultSet=statement.executeQuery(sqlQuery);
processResults(resultSet);
}catch(SQLExceptione){
//forwardtohandler
}finally{
if(null!=conn){
conn.close();
}
}
3.2清除临时文件
严重性中，可能性中。
(1)自动清除：
FiletempFile=Files.createTempFile("tempname",".tmp");
try{
BufferedWriterwriter=Files.newBufferedWriter(tempFile.toPath(),
StandardCharsets.UTF_8,StandardOpenOption.DELETE_ON_CLOSE)
//operatethefile
writer.newLine();
}catch(IOExceptione){
e.printStackTrace();
}
(2)手动清除。
3.3避免将bufer暴露给不可信代码
严重性中，可能性中。
wrap、duplicate创建的buffer应该以只读或拷贝的方式返回：
Charbufferbuffer；
publicDuplicator(){
buffer=CharBuffer.allocate(10);
}
/**获取只读的Buffer*/
publicCharBuffergetBufferCopy(){
returnbuffer.asReadOnlyBuffer();
}
3.4任意文件下载/路径遍历防范
严重性中，可能性高。
(1)校验用户可控的参数（推荐白名单）；
(2)文件路径保存到数据库，让用户提交文件对应的ID去下载文件：
<%
StringfilePath=getFilePath(request.getParameter("id"));
download(filePath);
%>
(3)判断目录和文件名：
if(!"/somedir/".equals(filePath)||!"jpg".equals(fileType)){
...
return-1;
}
(4)下载文件前做权限判断。
补充：禁止将敏感文件（如日志文件、配置文件、数据库文件等）存放在web内容目录下。
3.5非法文件上传防范
严重性高，可能性中。
在服务器端用白名单方式过滤文件类型，使用随机数改写文件名和文件路径。
if(!ESAPI.validator().isValidFileName(
"upload",filename,allowedExtensions,false)){
thrownewValidationUploadException("uploaderror");
}
补充：如果使用第三方编辑器，请及时更新版本。
4-序列化/反序列化操作
编码原则：不信任原则。
4.1敏感数据禁止序列化
严重性高，可能性低。
使用transient、serialPersistentFields标注敏感数据：
privatestaticfinalObjectStreamField[]serialPersistentFields={
newObjectStreamField("name",String.class),
newObjectStreamField("age",Integer.TYPE)
}
当然，正确加密的敏感数据可以序列化。
4.2正确使用安全管理器
严重性高，可能性低。
如果一个类的构造方法中含有各种安全管理器的检查，在反序列化时也要进行检查：
privatevoidwriteObject(ObjectOutputStreamout)throwsIOException{
performSecurityManagerChek();
out.writeObject(xxx);
}
补充：第三方组件造成的反序列化漏洞可通过更新升级组件解决；
禁止JVM执行外部命令，可减小序列化漏洞造成的危害。
5-运行环境
编码原则：攻击面最小化原则。
5.1不要禁用字节码验证
严重性中，可能性低。
启用Java字节码验证：Java-Xverify:allApplicationName
5.2不要远程调试/监控生产环境的应用
严重性高，可能性低。
(1)生产环境中安装默认的安全管理器，并且不要使用-agentlib，-Xrunjdwp和-Xdebug命令行参数：
${JAVA_HOME}/bin/java-Djava.security.managerApplicationName
(2)iptables中关闭相应jdwp对外访问的端口。
5.3生产应用只能有一个入口
严重性中，可能性中。
移除项目中多余的main方法。
6-业务逻辑
编码原则：安全设计API。
6.1用户体系
过程如下：
(1)identification<--宣称用户身份（鉴定提供唯一性）
|
|-->(2)authentication<--验证用户身份（验证提供有效性）
|
|-->(3)authorization<--授权访问相关资源（授权提供访问控制）
|
|-->RESOURCE
|
|-->(4)accountability<--日志追溯
(1)身份验证：
严重性高，可能性中。
多因素认证；
暴力破解防范：验证码、短信验证码、密码复杂度校验、锁定账号、锁定终端等；
敏感数据保护：存储、传输、展示（API接口、HTML页面掩码）；
禁止本地验证：重要操作均在服务器端进行验证。
(2)访问控制：
严重性高，可能性中。
从Session中获取身份信息；
禁用默认账号、匿名账号，限制超级账号的使用；
重要操作做到职责分离；
用户、角色、资源、权限做好相互校验；
权限验证要在服务器端进行；
数据传输阶段做好加密防篡改。
补充：oauth授权时授权方和应用方都要做好安全控制。
(3)会话管理：
严重性高，可能性中。
| 漏洞名称 | 防御方法 |
|---|---|
| 会话ID中嵌入URL | 会话ID保存在Cookie中 |
| 无Session验证 | 所有的访问操作都应基于Session |
| Session未清除 | 注销、超时、关闭浏览器时，都要清除Session |
| Session固定攻击 | 认证通过后更改SessionID |
| SessionID可猜测 | 使用开发工具中提供的会话管理机制 |
| 重放攻击 | 设置一次失效的随机数，或设置合理的时间窗 |
补充：设置认证Cookie时，需加入secure和httponly属性。
(3)日志追溯：
严重性中，可能性中。
记录每一个访问敏感数据的请求，或执行敏感操作的事件；
防范日志伪造攻击（输入校验）；
任何对日志文件的访问（读、写、下载、删除）尝试都必须被记录。
6.2在线支付
严重性高，可能性中。
支付数据做签名，并确保签名算法的可靠；
重要参数进行校验，并做有效性验证；
验证订单的唯一性，防止重放攻击。
6.3顺序执行
严重性高，可能性中。
对每一步的请求都要严格验证，并且要以上一步的执行结果为依据；
给请求参数加入随机key，贯穿验证的始终。
以上这篇浅谈Java开发中的安全编码问题就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持毛票票。