电子商务网站互联网安全防御攻略.docx

电子商务网站，互联网的安全防御相当重要，尤其是牵扯到支付这一块的。本文总结了一些比较通用的 web 安全防御常识，供大家参考一下，也希望可以和关心这一块的同行一起讨论一下这方面的话题。1. 信息传输加密https 使用对称加密还是非对称加密？对称加密使用 DES 还是 AES？非对称加密使用 RSA 还是 DSA？ 使用什么加密算法，在购买证书的时候就要确定。一般是用 RSA 2048 位。SSL 证书需要不需要购买？ 不需要购买的理由 - 我们使用HTTPS的目的就是希望服务器与客户端之间传输内容是加密的，防止中间监听泄漏信息，去证书服务商那里申请证书不划算，因为使用服务的都是固定客户和自己内部人士，所以我们自己给自己颁发证书，忽略掉浏览器的不信任警报即可； 需要购买的理由 - 用户体验好、专业性强。双向验证还是单向验证？ 单向验证验证的是服务器；双向验证服务器客户端互相验证。 对于服务器来讲，单向验证能够保证传输的数据加密过了；双向验证不仅保证传输数据加密，还能够保证客户端来源的安全性。 如果使用双向验证的话，需要客户端浏览器导入证书。 出于客户体验的考虑，大部分 https 网站使用的都是单向验证(比如CSDN 登录)，一些安全性要求高的使用的是双向验证(比如招行网上银行、支付宝)。证书是和域名绑定的，服务开放之前，域名确定、购买，https 证书的购买需要先搞定。2. 文件存储加密非对称加密使用什么加密算法，RSA 还是 DSA？非对称加解密的话，加解密比较慢，实现上使用 java 实现还是 c？3. 防御 XSS 攻击服务前台客户端，对用户输入进行 js 表单验证；目前，我们服务前台的客户端的表单验证也要交互一下后台，增加了后台负载，而且还留下了 XSS 攻击隐患；应该是接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交；对于对其他的特别是 javascript 相关的特殊字符一律过滤；对于某些 html 危险字符进行转义，比如 转义为 >， 转义为 <；对于存放敏感信息的 Cookie，对该 Cookie 添加 HttpOnly 属性，避免被攻击脚本窃取；服务前台服务器端，对用户输入再次验证；进行服务器端表单级验证，防止恶意用户模拟浏览器绕过 js 代码进行攻击；建议对于服务器端表单验证统一系统异常码，结合系统异常处理机制。客户端根据服务器端返回异常码显示相应信息，而不是将异常报告赤裸裸地展现给客户：一是用户体验不好，二者给恶意用户带来可趁之机；程序中使用ESAPI库预防XSS：javaview plaincopyprint?1. System.out.println(ESAPI.encoder().encodeForHTML(alert(););输出：<ahrefsdfs><a> < script > alert < script >4. 防御 SQL 注入同 3 防御 XSS 攻击中建议对于服务器端表单验证统一系统异常码条；服务前台客户端在进行表单级验证的需要对 drop、update、delete 等 SQL 进行消毒；服务前台服务器端再次进行服务器表单级验证的时候，需要再次对 drop、update、delete 等 SQL 进行消毒，防止恶意用户绕过 js 进行攻击；对敏感字符进行转义，比如 转义为 ；传统 jdbc 进行参数绑定，如javaview plaincopyprint?1. PrepareStatementpre=connection.prepare(“select*fromU=?”);2. pre.setString(1,”zhaoxin”);3. ResultSetrs=pre.executeQuery();hibernate 进行参数绑定，如javaview plaincopyprint?1. Stringhql=”fromU=: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/;autoindex on;当访问 03/test/ 这个 URL 时，正常情况应该遍历 html/test/ 这个目录，但是如果访问 03/test./ 这个 URL 时，则会遍历上一级目录 html/ 了。应该改为location /test aliashtml/test;autoindex on;或者location /test/ aliashtml/test/;autoindex on;或者直接禁用 autoindex 模块。nginx 版本的选择; 关于 nginx 的安全漏洞可以关注nginx 官方发布的安全公告或到其他一些漏洞发布平台上查找。 在安装 nginx 时建议使用自定义安装路径，如果采用默认安装路径，很容易被攻击者和一些自动化攻击工具猜测到，为其进行下一步的攻击提供便利。 在选择 nginx 版本时，需要关注是否存在安全漏洞和版本的稳定性。一般选择最新的稳定版本，这样可以在稳定性和安全之间取得一个平衡。修改/隐藏 Nginx Banner 信息;日志安全; 修改日志的默认保存路径，然后设置只允许管理员有日志存放目录的安全控制权限。nginx 权限设置; 给 nginx 一个权限比较低的身份运行，可以通过修改 nginx.conf 进行调整。应用服务器、数据库也应该遵循这个原则。关闭服务器标记; 如果开启的话(默认为开启)，所有错误页面都会显示服务器的版本和信息。设置自定义缓存以预防缓存区溢出攻击;12. web 服务器和应用服务器目录权限设置原则如果目录有写入权限，一定不要分配执行权限； 比如网站上传目录和数据库目录一般需要分配写入权限，但一定不要分配执行权限。如果目录有执行权限，一定不要分配写入权限；一般目录只需分配读取权限即可；应用服务器和数据库部署在不同的服务器上；文件属主与应用服务器进程属主不同(一般设置文件属主为 root)；控制脚本只运行访问应用项目目录下的文件;13. 代码混淆静态 js 代码混淆；应用程序 java 代码混淆；14. 数据库安全防护敏感字段的加密存储；比如用户密码、银行账号等等。禁用远程访问功能；经常分析MySql访问日志；比如通用查询日志对每一个客户端连接以及每一次查询情况都进行了时间戳记录，通过这种日志往往可以查出网络入侵等活动的源头。应用服务器数据库配置文件中的用户名和密码加密保存；15. 人工/自动对web攻击的定期监测定期分析web日志； 关键字检查，如insert delete update select等； 特殊字符参数检查，如;-/*=等； 特殊表达式检查，如1=1 1=2 a or a=a等；定期分析防火墙日志； 服务器主动对外发起的连接； TFTP协议FTP 协议数据；定期分析数据库日志 同 14. 数据库安全防护条目提及的访问日志条； 数据库备份记录； 新库、新表建立记录； 存储过程执行记录； 数据的导入导出记录；定期分析IDS日志； 搜索SQL攻击记录的分析； WEB端口连接IP分布以及请求分布；定期检查WEB目录文件； 关键字搜索检查； 文件修改时间检查； 文件最后访问时间检查； 特殊文件名文件检查； 上传文件夹检查； 文件大小检查；16. 网站运行监控没有监控的网站，犹如盲人骑瞎马，夜半临深渊而不知，生死尚且未卜，就更别