搜索
电子商务网站，互联网的安全防御相当重要，尤其是牵扯到支付这一块的。本文总结了一些比较通用的web安全防御常识，供大家参考一下，也希望可以和关心这一块的同行一起讨论一下这方面的话题。1.信息传输加密https使用对称加密还是非对称加密？对称加密使用DES还是AES？非对称加密使用RSA还是DSA？使用什么加密算法，在购买证书的时候就要确定。一般是用RSA2048位。SSL证书需要不需要购买？不需要购买的理由-我们使用HTTPS的目的就是希望服务器与客户端之间传输内容是加密的，防止中间监听泄漏信息，去证书服务商那里申请证书不划算，因为使用服务的都是固定客户和自己内部人士，所以我们自己给自己颁发证书，忽略掉浏览器的不信任警报即可；需要购买的理由-用户体验好、专业性强。双向验证还是单向验证？单向验证验证的是服务器；双向验证服务器客户端互相验证。对于服务器来讲，单向验证能够保证传输的数据加密过了；双向验证不仅保证传输数据加密，还能够保证客户端来源的安全性。如果使用双向验证的话，需要客户端浏览器导入证书。出于客户体验的考虑，大部分https网站使用的都是单向验证(比如CSDN登录)，一些安全性要求高的使用的是双向验证(比如招行网上银行、支付宝)。证书是和域名绑定的，服务开放之前，域名确定、购买，https证书的购买需要先搞定。2.文件存储加密非对称加密使用什么加密算法，RSA还是DSA？非对称加解密的话，加解密比较慢，实现上使用java实现还是c？3.防御XSS攻击服务前台客户端，对用户输入进行js表单验证；目前，我们服务前台的客户端的表单验证也要交互一下后台，增加了后台负载，而且还留下了XSS攻击隐患；应该是接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交；对于对其他的特别是javascript相关的特殊字符一律过滤；对于某些html危险字符进行转义，比如转义为>，转义为<；对于存放敏感信息的Cookie，对该Cookie添加HttpOnly属性，避免被攻击脚本窃取；服务前台服务器端，对用户输入再次验证；进行服务器端表单级验证，防止恶意用户模拟浏览器绕过js代码进行攻击；建议对于服务器端表单验证统一系统异常码，结合系统异常处理机制。客户端根据服务器端返回异常码显示相应信息，而不是将异常报告赤裸裸地展现给客户：一是用户体验不好，二者给恶意用户带来可趁之机；程序中使用ESAPI库预防XSS：[java]viewplaincopyprint?1.System.out.println(ESAPI.encoder().encodeForHTML(ahref='sdfs'/ascriptalert();/script));输出：<ahref='sdfs'></a><script>alert();</script>4.防御SQL注入同3防御XSS攻击中建议对于服务器端表单验证统一系统异常码条；服务前台客户端在进行表单级验证的需要对drop、update、delete等SQL进行消毒；服务前台服务器端再次进行服务器表单级验证的时候，需要再次对drop、update、delete等SQL进行消毒，防止恶意用户绕过js进行攻击；对敏感字符进行转义，比如'转义为\'；传统jdbc进行参数绑定，如[java]viewplaincopyprint?1.PrepareStatementpre=connection.prepare(“select*fromUserwhereuser.name=?”);2.pre.setString(1,”zhaoxin”);3.ResultSetrs=pre.executeQuery();hibernate进行参数绑定，如[java]viewplaincopyprint?1.Stringhql=”fromUseruserwhereuser.name=:customername”;2.Queryquery=session.createQuery(hql);3.query.setParameter(“customername”,name,Hibernate.STRING);iBATIS/MyBatis进行参数绑定，在SQL语句的节点中，设置parameterClass=java.util.Map即可，程序里把参数封装到Map中;5.防御CSRF攻击使用Struts2的表单标签，其中需要增加token标签；重要的节点如复核，加一个验证码验证；检查HTTP请求头的Referer域，验证是否合法；6.划款环节的安全加强服务前台登录需要动态口令；每一笔划款请求需要动态口令；每一笔划款短信、邮件通知客户；设定限额等风险规则，超过就预警，需额外人工授权才能审核通过；7.避免表单重复提交使用Struts2的表单标签，其中需要增加token标签；对上传文件进行哈希库记录验证，如有重复询问客户是否继续；关键接口的幂等性设计；比如划款操作，由于网络等原因服务器端的返回结果丢失掉了，用户以为上一次操作失败，刷新页面或者再次提交，这样就划了两次款：划款接口使用幂等设计之后，任何一步由于网络等原因失败或超时，客户端都可以随意重试，直到获得正确结果：虽然create_ticket不是幂等的，但在这种设计下，它对系统状态的影响可以忽略，我们只需要保证idempotent_withdraw是幂等的即可。当然，如果create_ticket也能设计成幂等的，那就万无一失了。8.nginx反向代理nginx是我们服务器对外的第一层屏障；通过它我们可以轻松进行各种安全设定，比如禁止IP、限制IP并发数(这个可以预防DOS攻击)、设置timeout时间(这个也可以预防DOS攻击)、限制用户带宽等等；nginx还能对外屏蔽服务器接口路径、静态文件真实路径，避免路径遍历攻击；nginx有个专门预防XSS、注入攻击的模块naxsi；动静分离，加快响应速度，降低tomcat负载；负载均衡；9.及时更新Struts2框架10.设置文件上传白名单，或者干脆限制为xls、xlsx，以避免上传文件攻击11.nginx漏洞利用和安全加固nginx配置错误而导致目录遍历漏洞;比如location/test{aliashtml/test/;autoindexon;}当访问这个URL时，正常情况应该遍历html/test/这个目录，但是如果访问这个URL时，则会遍历上一级目录html/了。应该改为location/test{aliashtml/test;autoindexon;}或者location/test/{aliashtml/test/;autoindexon;}或者直接禁用autoindex模块。nginx版本的选择;关于nginx的安全漏洞可以关注nginx官方发布的安全公告或到其他一些漏洞发布平台上查找。在安装nginx时建议使用自定义安装路径，如果采用默认安装路径，很容易被攻击者和一些自动化攻击工具猜测到，为其进行下一步的攻击提供便利。在选择nginx版本时，需要关注是否存在安全漏洞和版本的稳定性。一般选择最新的稳定版本，这样可以在稳定性和安全之间取得一个平衡。修改/隐藏NginxBanner信息;日志安全;修改日志的默认保存路径，然后设置只允许管理员有日志存放目录的安全控制权限。nginx权限设置;给nginx一个权限比较低的身份运行，可以通过修改nginx.conf进行调整。应用服务器、数据库也应该遵循这个原则。关闭服务器标记;如果开启的话(默认为开启)，所有错误页面都会显示服务器的版本和信息。设置自定义缓存以预防缓存区溢出攻击;12.web服务器和应用服务器目录权限设置原则如果目录有写入权限，一定不要分配执行权限；比如网站上传目录和数据库目录一般需要分配写入权限，但一定不要分配执行权限。如果目录有执行权限，一定不要分配写入权限；一般目录只需分配读取权限即可；应用服务器和数据库部署在不同的服务器上；文件属主与应用服务器进程属主不同(一般设置文件属主为root)；控制脚本只运行访问应用项目目录下的文件;13.代码混淆静态js代码混淆；应用程序java代码混淆；14.数据库安全防护敏感字段的加密存储；比如用户密码、银行账号等等。禁用远程访问功能；经常分析MySql访问日志；比如通用查询日志对每一个客户端连接以及每一次查询情况都进行了时间戳记录，通过这种日志往往可以查出网络入侵等活动的源头。应用服务器数据库配置文件中的用户名和密码加密保存；15.人工/自动对web攻击的定期监测定期分析web日志；关键字检查，如insertdeleteupdateselect等；特殊字符参数检查，如';--/*=等；特殊表达式检查，如1=11=2a'or'a'='a等；定期分析防火墙日志；服务器主动对外发起的连接；TFTP协议FTP协议数据；定期分析数据库日志同14.数据库安全防护条目提及的访问日志条；数据库备份记录；新库、新表建立记录；存储过程执行记录；数据的导入导出记录；定期分析IDS日志；搜索SQL攻击记录的分析；WEB端口连接IP分布以及请求分布；定期检查WEB目录文件；关键字搜索检查；文件修改时间检查；文件最后访问时间检查；特殊文件名文件检查；上传文件夹检查；文件大小检查；16.网站运行监控没有监控的网站，犹如盲人骑瞎马，夜半临深渊而不知，生死尚且未卜，就更别说提高可用性、减少故障率、监测黑客入侵了。Nagios；开源。适合于大规模分布式系统。与Ganglia相比它能够健康检查并智能报警，将管理员从日常烦琐的工作中解放出来。Ganglia；开源。适合于大规模分布式系统。与Nagios相比它能够提供更加精确的数据，通常和Nagios一起使用。nmon；开源。适合于小规模应用系统。JMeterPerfMon服务器性能指标监控插件；开源。适合于配合JMeter压测时使用。