web安全-最终版

1、 目录目录 q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-url-encoded Content-Lenght: 59 User-Agent: Mozilla/4.0 Host: Connection: Keep-Alive Cookie: JSESSIONID=0000dITLGLqhz1dKkPEtpoYqbN2 uid=fred这两句sql都符合 string,int,string的模式 999是不可能符合的条件 ，这样union的结果就只 剩第二句sql查询的内容 SQL注入：规避SQL注入 n

2、严格限定参数类型严格限定参数类型 明确参数检验的边界，明确参数检验的边界，必须在服务端执行数据验证 n采用参数化查询的方法（推荐）采用参数化查询的方法（推荐） n内置过滤系统（本质是黑名单，很常见但是不推荐）内置过滤系统（本质是黑名单，很常见但是不推荐） SQL注入：安全编码 安全编码不难，真正困难的是如何做到全面安全，安全编码不难，真正困难的是如何做到全面安全， 这需要良好的程序设计以及编码习惯。支离破碎这需要良好的程序设计以及编码习惯。支离破碎 的设计与随意混杂的编码难以开发出安全的系统。的设计与随意混杂的编码难以开发出安全的系统。 各种语言与数据库的实际情况也有所区别，所以各种语言与数据

3、库的实际情况也有所区别，所以 需要具体问题具体分析。需要具体问题具体分析。 1.输入验证输入验证 数字型的输入必须是合法的数字； 字符型的输入中对进行特殊处理； 验证所有的输入点，包括Get，Post，Cookie以及其 他HTTP头； 2.使用符合规范的数据库访问语句使用符合规范的数据库访问语句 正确使用静态查询语句，如PreparedStatement SQL注入： PreparedStatement nPreparedStatement为预编译指令为预编译指令 nPreparedStatement不允许在插入时改变查 询的逻辑结构 n所以PreparedStatement将SQL语句预先

4、编 译，执行前语句已经准备好了，执行阶段 只是把输入串作为数据处理,不再需要对 SQL语句进行解析 SQL注入： PreparedStatement 在在JSPJSP中要禁止使用中要禁止使用StatementStatement，如下的代码会导致，如下的代码会导致SQLSQL注入：注入： Bubble String sql = “select * from Users where name=” + name; PreparedStatement pstmt = con.prepare(sql); String sql = “select * from 表表 where 用户名用户名=?” pst

5、mt.setInt(1, request.getParameter(“name”); PreparedStatement pstmt = con.prepare(sql); Statement stmt = con.createStatement(); stmt.executeUpdate(select * from 表 where 用户名 = + 变量值 +); 应当全部使用PreparedStatement来防止SQL注入 但是在使用PreparedStatement，也要注意符合编码规范，如下的方法也 会导致SQL注入： 安全安全 危险危险 危险危险 SQL注入： Mysqli n并不是

6、所以数据库都支持并不是所以数据库都支持 PreparedStatement nMysql就明确表示不支持，但是就明确表示不支持，但是mysql可以可以 使用自己的预编译扩展使用自己的预编译扩展-mysqli nmysqli 同样是执行一个预备好的语句，杜 绝SQL的可能 SQL注入：数据库加固 除了在代码设计开发阶段预防除了在代码设计开发阶段预防SQLSQL注入外，对数据库进行加固也能够注入外，对数据库进行加固也能够 把攻击者所能造成的损失控制在一定范围内；把攻击者所能造成的损失控制在一定范围内； 主要包括：主要包括： 最小权限原则，最小权限原则，禁止将任何高权限角色（例如禁止将任何高权限角色

7、（例如sasa，dbadba等等）赋于应等等）赋于应 用程序数据库账号。更安全的方法是单独为应用创建有限访问帐户。用程序数据库账号。更安全的方法是单独为应用创建有限访问帐户。 拒绝用户访问敏感的系统存储过程，如前面示例的拒绝用户访问敏感的系统存储过程，如前面示例的 xp_dirtree,xp_cmdshellxp_dirtree,xp_cmdshell等等；等等； 限制用户所能够访问的数据库表；限制用户所能够访问的数据库表； 目录目录 过滤：过滤：将script,style,iframe,onmouseover等有害 字符串去掉，但是保留 scriptalert(XSS)/script imp

8、orthttp:/ 更多实例可见：更多实例可见：/xss.html 综合起来有综合起来有 91种种HTML标签标签,十多种编码方式十多种编码方式,数种对象类型数种对象类型 MySpaceMySpace即即 采用的过滤采用的过滤 XSS漏洞：转义 String title = request.getParameter(“title”); String id = request.getParameter(“id”); . String title = request.getParameter(“title”); String id = request.getPa

9、rameter(“id”); . 把输入的值转义成html代码 对策：转义比过滤更好 安全安全 危险危险 XSS漏洞：防范措施总结防范措施总结 一.过滤： 有时候过滤会导致意外的结果，例如alices 变成了alices。 有时候需要多次过滤，例如script过滤掉后还是。 需要注意多个过滤器的先后次序。当多个过滤器一起生效时，有可能后进行的过滤导致前面 的过滤失效。例如过滤器1要过滤ABC，过滤器2要过滤DEF，那么ABDEFC在依次通过1，2 过滤器后变成了ABC，这样相当于绕开过滤器1。 二.输入编码： 输入编码往往可以有全局的解决方案，从设计的角度来看，这是最佳的。 一旦数据已经入库，

10、就难以用输出编码处理。 三.输出编码： 输出编码有助于开发者细粒度控制输出，但也导致了工作量的增加。 输出编码可以解决输入编码无法处理的已入库数据。 四.用户安全加固： 小心点击来源不明的URL。 对浏览器进行安全加固，例如禁止ActiveX。 永远不要点击自动登录信息！ 目录目录 String pass = request.getParameter(“pass”); PreparedStatement ps = con.prepareStatement(“update UserTB set password=? Where user=?”); ps.setString(1,user); ps

11、.setString(2,pass); con.executeUpdate(); CSRF：案案例例2 案例案例2： 支持通过保留cookie自动登录的功能，这样在cookie有效期 内，用户访问就会以他们上次在此主机登录的用户名自动登 录（例如Gmail的Remember me on this computer）。 另外，上有个链接可以通过get直接给指定对象转账，例如： http:/ 这段这段FCKeditor代码可以通过上传文件后面加个代码可以通过上传文件后面加个.就可以上传成功了如：就可以上传成功了如： shell.php. 在在windows系统上系统上shell.php.=shel

12、l.php；在；在*nix系统一系统一 般使用般使用apache，在，在apache里里shell.php.将认为是将认为是php文件而执行。文件而执行。 编辑器上传漏洞是最危险的，使用编辑器上传漏洞是最危险的，使用 FCKeditor、eWebEditor、 Cuteditor 、Freetextbox、Webhtmleditor、Kindeditor等编辑器的都存在危险， 引用时应删除其不必要的上传功能 文件上传漏洞3：不随机重命名的危害不随机重命名的危害 n在在win2000下下 代表截断，如果一人上传1.asp .jpg到 win2000上就会变成1.asp n以前大名鼎鼎的动网上传漏

13、洞是使用的16进制00来截断文 件名或路径而造成上传漏洞，现在虽然已经灭绝，但是使 用java的程序员还应注意，因为java本身支持16进制00截 断，上传一个1.jsp00.jpg将变成1.jsp n很多由于web service,中间件自身存在解析漏洞，造成 1.asp;.jpg,1.php.aaa之类的可以解析 n所以重命名文件名是必要的所以重命名文件名是必要的 文件上传漏洞：解决方案 n 解决方案 首先编码者需要对上传页面代码严格把关，特别是在保存文件的时候， 考察可能出现的异常字符，如如;, ./，.，空字符等。 其次，对文件扩展名检查要采取“允许jpg,gif”这样的检查，而不要采

14、 取“不允许asp”这样的检查，例如IIS允许执行.cer类型的脚本。 不可以使用本地的JS来进了后缀名验证，必须再服务器端进行验证 最好对上传文件的目录设置不可执行，这可以通过最好对上传文件的目录设置不可执行，这可以通过web服服 务器配置加固实现。务器配置加固实现。 文件包含漏洞 n 定义： 文件包含漏洞，如果允许客户端用户输入控制动态包含在服务器端的 文件，会导致恶意代码的执行及敏感信息泄露，主要包括本地文件包含 和远程文件包含两种形式 n 解决方案： 1.严格检查变量是否已经初始化。 2.建议假定所有输入都是可疑的，尝试对所有输入提交可能可能包含的文 件地址， 包括服务器本地文件及远程

15、文件，进行严格的检查，参数中不 允许出现./之类的目录跳转符。 3.严格检查include类的文件包含函数中的参数是否外界可控。 4.不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。 5.在发布应用程序之前测试所有已知的威胁。 参考： http:/ 文件包含漏洞-示例 jsp:include page= flush=true/ 示例 ： test.jsp?test=./././././etc/passwd - if ($act = “view”) $file = $_GETfile; include $file; index.php?act=view jstack += Fil

16、e.separator + bin + File.separator + jstack; final ByteArrayOutputStream baos = new ByteArrayOutputStream(); Process proc = Runtime.getRuntime().exec(jstack); final InputStream pis = proc.getInputStream(); final InputStream per = proc.getErrorStream(); 此处的问题是此处的问题是exec执行内容的部分由外部提交的参数获得，从而造成了执行内容的部分由

17、外部提交的参数获得，从而造成了 危险，如果危险，如果jstack.jsp?exe=././././windows/system32/cmd ipconfig 就能造成命令执行就能造成命令执行 命令注入执行漏洞命令注入执行漏洞 $res = preg_replace(/(w+).$depr.(.$depr./+)/e, $var1=2;, implode($depr,$paths); 命令注入执行漏洞命令注入执行漏洞 命令执行漏洞发生在PHP的地方是最常见的，php里有多个函数可可以动态执 行，如： call_user_func() call_user_func_array() create_f

18、unction() preg_replace() 如下面这段thinkphp开发框架中的正则表达式代码就造成了命令执行漏洞： 造成该正则表达式漏洞的原因在于， PHP会对用双引号包起来的字符进行 解析，preg_replace()使用了/e 参数时可以执行代码，这种情况下如果2 使用双引号，那么2的内容就会被当成PHP代码执行。 因此PHP程序开发者应避免使用双引号来定义参数。 如下代码：如下代码： filepath=request.getparameter(filepath); File f = new File(d:tomcatwebappsROOTdown +filepath); Fil

19、eInputStream inStream = new FileInputStream(f); 如此当有人输入如下如此当有人输入如下URL:download.jsp?filepath=././conf/tomcat- users.xml 就能够跨目录下载就能够跨目录下载tomcat管理用户的密码，从而登陆管理用户的密码，从而登陆manager/html对对 系统造成危害。系统造成危害。 如果使用先打开目录的方式将会提高安全性如果使用先打开目录的方式将会提高安全性 File f = new File(d:tomcatwebappsROOTdown); 文件下载漏洞文件下载漏洞 当然也可以使用过滤

20、当然也可以使用过滤后缀名后缀名和和./的方式的方式 但过滤但过滤./应该注意其应该注意其. ，./等绕过方式等绕过方式 过滤后缀名应该注意区分大小写，如下代码：过滤后缀名应该注意区分大小写，如下代码： $filename = $_GETa; if(!eregi(.php$, $filename) echo “不允许下载该类型的文件不允许下载该类型的文件; readfile($filename); 该代码由于使用的该代码由于使用的eregi()正则函数而不是使用更为严谨的区分大小写的正则函数而不是使用更为严谨的区分大小写的 函数函数ereg()，因此提交，因此提交url：download.php

21、?filename=download.pHP 就可绕过就可绕过(linux系统本身区分大小写但可提交系统本身区分大小写但可提交download.php.)。 文件下载漏洞文件下载漏洞 XPath 注入攻击 Ben Elmore abc test123 Shlomy Gantz xyz 123test XPath xpath = factory.newXPath(); XPathExpression expr = pile(/users/userloginID/text()=+loginID + and password/text()=+password+ /firstname/text();

22、Object result = expr.evaluate(doc, XPathConstants.NODESET); NodeList nodes = (NodeList) result; /绕过身份验证 /users/userLoginID/text()= or 1=1 and password/text()= or 1=1 登录用户名输入以上红色部分，密码任意输 随 着简单 XML API、Web 服务和 Rich Internet Applications (RIAs) 的发 展,已经有很多人使用 XML 文档代替关 系数据库，但XML 应用程序可能容易 受到代码注入的攻击，尤其是 X

23、Path 注入攻击 整数溢出 示例代码： - 某人订购大量商品 number = 42949671; 计算出来的总价total = -196 没有限定num 0) int total = num * 100; /计算总价格 是cookies过期时间未设置，可能会引发一些cookies欺骗攻击 n风险风险 可能会窃取或操纵客户会话和 cookie，它们可能用于模仿合法用户，从而 使黑客能够以该用户身份查看或变更用户记录以及执行事务 n解决方案解决方案 始终生成新的会话，供用户成功认证时登录。在登录页面上加上一段代码： 在登陆页面上加的这段代码的作用就是，将用户进入登陆页面时所产生的会话 ( se

24、ssion) 清空，然后让跟踪这个会话的cookie过期，这样服务器就不再掌握有关这 个会话的任何信息了。要想与服务器继续通信，就要产生一个新的会话才行。于是 会话标示就更新了，假如晚上登录被盗cookie，但是黑客在睡觉第二天醒来失效了 会话标识未更新会话标识未更新 注：注：如果是jsp+servlet，这段代码放jsp页面程序的任何位置都可以。 如果是struts框架框架，这几行代码只能加到jsp页面程序的最后面页面程序的最后面。因为struts框架在初 始化时会创建session对象，并把一些参数放在session里，然后再执行页面代码。 request.getSession().inv

25、alidate();/清空session if (request.getCookies()!=null) Cookie cookie = request.getCookies()0;/ 获取cookie cookie.setMaxAge(0);/ 让cookie过期 目录目录 location.href=$ctx/admin/login/logout.jsp; /如果禁用了客户端的脚本代码，直接访问后台页面，不会被跳转 到登陆页面，可以看到后台所有内容。 提示：不能用JS代码来完成某些必须要执行的信息。得用服务端脚 本语言如上面可以用response.sendRedirect() 变量注册顺序

26、：Php168 CMS文件包含漏洞 . elseif(ereg(-_0-9a-zA-Z+)$,$_GETjob)|ereg(-_0-9a-zA- Z+)$,$_POSTjob) require(dirname(_FILE_)./.global.php); if(is_file(PHP168_PATH.inc/job/$job.php) include(PHP168_PATH.inc/job/$job.php); 如果开了全局的话,就可以用gpc的变量注册顺序来pass那个 正则判断 参考：http:/ Json hijacking/Json劫持漏洞 JSON(JavaScript Object

27、 Notation) 是一种轻量级的数据交换 格式。易于人阅读和编写。同时也易于机器解析和生成。JSON采用 完全独立于语言的文本格式，也使用了类似于C语言家族的习惯（包 括C, C+, C#, Java, JavaScript, Perl, Python等）。这些特性使 JSON成为理想的数据交换语言。这种纯文本的数据交互方式由于可 以天然的在浏览器中使用，所以随着ajax和web业务的发展得到了广 大的发展，各种大型网站都开始使用。 但是如果这种交互的方式用来传递敏感的数据，并且传输的时 候没有做太多安全性控制的话将导致安全漏洞，根据敏感信息的不 同导致会导致应用遭受不同级别的攻击。 Js

28、on hijacking/Json劫持漏洞：示例 n某省运营商网上营业厅修改任意手机号密码漏洞 http:/ onParam=%22dynamicURI%22%3A%22%2FmmxgBusiness% 22%2C%22dynamicParameter%22%3A%22method%22%3A% 22modifyPwd%22%2C%22busiNum%22%3A%22MMFW_MMC Z%22%2C%22mobile%22%3A%2213951909864%22%2C%22n ewPwd%22%3A%22987321%22%2C%22checkOld%22%3A%22 0%22%2C%22ca

29、rdNum%22%3A%22%22%2C%22dynamicDat aNodeName%22%3A%22mmczBusinessNode%22 劫持危害劫持危害 n以上方法在本地拦截并更改了提交出去的以上方法在本地拦截并更改了提交出去的 手机号码，就能造成越权查看别人手机号手机号码，就能造成越权查看别人手机号 的持有人姓名，账单，余额等，一些网银的持有人姓名，账单，余额等，一些网银 系统甚至可以转账。系统甚至可以转账。 n还有一种常见的危害，比如商城购物，比还有一种常见的危害，比如商城购物，比 如积分兑换的地方，标价如积分兑换的地方，标价2000积分兑换一积分兑换一 个手电筒，你本地篡改为个手

30、电筒，你本地篡改为1个积分再次提交个积分再次提交 出去，就能造成出去，就能造成1积分成功购买了手电筒。积分成功购买了手电筒。 flash安全策略 flash作为一款浏览器的第三方插件，是对浏览器功能的延伸，已经 是web必不可少的元素。很多web系统因为业务应用的需求,允许用户上 传flash文件。 flash在页面展示时含有的丰富功能， 同时对安全策略带来了挑战， 其潜在危险甚至超过js flash的跨域策略crossdomain.xml 利用利用flash进行攻击进行攻击 参考：http:/ 拖动前拖动前 拖动后拖动后 这个DEMO的思想是：在小球的上面加入隐藏层，在海豚的嘴上方加入隐 藏

31、层。本质上就是诱惑 用户把中的内容拖放到中去。 当操作成功后，会把你拖动的数据打印在页面上。如果你愿意，只要再加几行代码， 数据就可以保存在服务器上了。细心的朋友可以看看源代码，里面的操作我都写成 了独立的函数，应该很好理解。 容错处理不当 public static void main(String args) try catch (Exception e) e.printStackTrace(); /直接将错误返回到客户端，造成系统信息泄露(如：网站绝对路径， SQL语句) 平台安全特性 nIIS文件名解析漏洞文件名解析漏洞 nApache文件名解析漏洞文件名解析漏洞 nNginx文件名解

32、析漏洞文件名解析漏洞 nStruts2框架任意代码执行框架任意代码执行 文件名解析漏洞 nIIS6文件夹解析漏洞文件夹解析漏洞 /test.asp/111.jpg（忽略忽略/后的部分后的部分） nIIS6文件名解析漏洞文件名解析漏洞 /test.asp;1.jpg （忽略忽略;后的部分后的部分） nApache文件名解析漏洞文件名解析漏洞 /test.php.xxx （忽略忽略.后的部分后的部分） nNginx cgi模式文件名解析漏洞模式文件名解析漏洞 /test.jpg/a.php 注：攻击者在在/test.jpg后加上后加上a.php就可以实现让 nginx以php来解析任何类型的文件了

33、。 Struts2框架任意代码执行框架任意代码执行 n示例示例 http:/mydomain/MyStruts.action?(u0023_memberAccessallowStaticMethodAccess)(meh)=tr uew.write(request.getParameter(c);w.cl ose();u0025u003e)=1 OGNL访问对象需要加#号前缀进行标记(根对象除外) 参数过滤器不允许参数名中出现“#”字符，但如果使用了Java的 unicode字符串表示u0023，攻击者就可以绕过保护，修改保护Java方 式执行的值 (详见： http:/ 注意框架的补丁注意框

34、架的补丁 n因此应谨慎使用第三方的因此应谨慎使用第三方的MVC框架，及时框架，及时 更新其补丁更新其补丁 nStruts2 ,CakePHP,thinkPHP等框架都存等框架都存 在严重的命令执行漏洞在严重的命令执行漏洞 目录目录 /线上、本地、220测试机 if (!(referrer.startsWith(3) return false; return true; 页面HTML源代码中会出现页面注释内容泄漏，包括开 发人员名称、邮件地址等，所以在页面中针对此类注释不应该 使用显式注释方式，多采用隐式注释方式。 以下是显式注释：以下是显式注释： 以下是隐式

35、注释：以下是隐式注释： 页面注释修改页面注释修改 为防止用户退出后，点击浏览器的“后退”按钮仍可以显示用户 退出前访问的最后一个页面，需要强制所有页面不缓存。 建议在web管理后台程序管理后台程序的过滤器里增加如下代码： 禁止页面缓存禁止页面缓存 /只是请求或响应消息不缓存 response.setHeader(Cache-Control, no-cache); /在请求消息中发送将使得请求和响应消息都不使用缓存 response.setHeader(Cache-Control, no-store); /缓存距离过期的时间为0毫秒，即缓存立即过期 response.setDateHeader(

36、Expires, 0); /页面不缓存 response.setHeader(Pragma, no-cache); PreparedStatement，通过预编译并存储在PreparedStatement 对象池中。下面实例代码是采用预编译语句的查询的SQL实现， 请参考： 隐患代码隐患代码 Sql=“select * from t_sys_user where username=”+变量1+” and password=”+变量2+” 安全代码安全代码 采用预编译语句的采用预编译语句的SQL实现实现 StringBuffer sbSql = new StringBuffer(50); sbS

37、ql.append(“select 字段1，字段2，字段3”); sbSql.append(“ from t_sys_user”); sbSql.append(“ where username = ? “); sbSql.append(“ and password = ? “); Connection conn = 获取数据库连接 PreparedStatement pstmt = conn.prepareStatement(sbSql.toString(); int parIndex=1; pstmt.setString(parIndex+,变量1); pstmt.setString(par

38、Index+,变量2); ResultSet rs = pstmt.executeQuery(); 网站存在上传文件的功能，恶意用户可以绕过客户端页面 的验证，模拟请求上传文件处理服务端，将一些可运行页面(例 如：jsp、php、asp等)上传到服务端，访问该页面会对网站安全 造成很大影响。 解决该漏洞步骤如下： 1.客户端对上传文件类型做校验。 2.上传处理服务端对文件类型进行二次校验。 3.文件上传到服务器之后，如果是属于临时文件，则在业务逻辑 处理完成之后，将该原始文件删除。 注：注：还有其他文件上传方式（比如彩信彩信的上行jsp附件，就最好 不放到web路径下） 文件文件上传上传校验校

39、验 目录目录 & 引言引言 & 高危漏洞分析与对策高危漏洞分析与对策 & 程序开发安全措施程序开发安全措施 & 平台部署与维护措施平台部署与维护措施 uWEB应用服务器配置 uWEB应用配置403、404、500通用处理页面 u权限管理 & 程序安全开发流程程序安全开发流程 nTomcatTomcat 线上tomcat禁用自带的管理应用以及示例应用 配置tomcat禁止列表显示文件。 Tomcat不以ROOT/system运行。 tomcat下禁止不安全的http方法（DELETE、PUT、 OPTIONS、TRACE、HEAD等协议） nApacheApache 配置非超级用户不能修改应用目

40、录内容。 配置禁止apache目录访问显示文件 增强apache日志记录，对运行错误、用户访问等日志都记 录。 禁止不安全的HTTP方法 WEB应用服务器配置应用服务器配置 应用常见403、404、500等访问异常，需要配置各自独立 重定向页面。 在应用web.xml中增加以下内容配置，各个异常显示页面 需要单独制作。 WEB应用配置应用配置403、404、500通用处理页面通用处理页面 403 /error/403.html 404 /error/404.html 500 /error/500.html n上传文件目录的权限原则：上传文件目录的权限原则： 权限最小化原则；权限最小化原则； 能

41、写入的目录不能执行，能执行的目录不能写入能写入的目录不能执行，能执行的目录不能写入 n数据库帐号权限原则：数据库帐号权限原则： 权限最小化原则；不要给应用权限最小化原则；不要给应用dba等数据库管理权限等数据库管理权限 不要分配不要分配跨库权限跨库权限。 数据库连接的配置文件中关键信息要加密数据库连接的配置文件中关键信息要加密 权限管理权限管理 目录目录 & 概述概述 & WEBWEB代码常见的安全问题代码常见的安全问题 u SQL注入 u 跨站脚本漏洞(XSS) u 跨站点请求伪造（CSRF） u & 程序开发安全具体措施程序开发安全具体措施 & 平台部署与维护具体措施平台部署与维护具体措施

42、 & 程序安全开发流程程序安全开发流程 业界思路 开始 获取和开 发 执行 操作与维 护 发布阶部 署段 培训需求 设计实施测试发布响应 主流厂商和组织通过安全开发生命周期改进 微软 SDL 设计验证渗透测 试 安全开发流程 安全开发工具 安全开 发 安全需求 威胁建模 安全设 计 CSDL OWASP TOP 10 通过评估风险改进 推荐安全的开发模式推荐安全的开发模式 需求需求设计设计实施实施测试测试 发布和发布和 响应响应 安全需求 分析 攻击面分析 威胁建模 安全设计原 则 静态分析 Fuzzing 测试 基线检测 渗透测试 应急响应 系统监控 开发安全规 范 培训与教育 安全设计方

43、案 如果数据在传如果数据在传 输过程中没有输过程中没有 加密，就有可加密，就有可 能被截获、篡能被截获、篡 改改 需求需求 采用采用HTTPS 对通信数据进对通信数据进 行加密，以保行加密，以保 障数据的保密障数据的保密 性性 设计设计 避免使用特定避免使用特定 的危险的危险API如如 strcpy, sprintf, 避免缓冲区溢避免缓冲区溢 出漏洞出漏洞 实施实施 通过动态构建通过动态构建 SQL语句以证语句以证 明对用户输入明对用户输入 进行了过滤以进行了过滤以 避免了避免了SQL注注 入攻击入攻击 测试测试 入侵者通过入侵者通过 JSP程序提交程序提交 上传了页面文上传了页面文 件，清

44、除木马件，清除木马 程序并提供整程序并提供整 改建议改建议 应急应急 安全编程规范安全技术讲解安全测试原理持续安全学习 SSDLC 需求分析需求分析 设计设计 实现实现测试测试 安全需求工程 设计安全 发布发布 安全编码 补丁管理 配置加固 软件黑盒测试 渗透性测试 代码安全审计 安全软件开发生命周期依然是Web安全的基石。 编码阶段：输入过滤、输入编码、 输出过滤、输出编码 测试阶段：代码审计、XSS测试等， 可手工也可以结合自动工具 部署阶段：IDS/IPS、Web应用防 火墙、客户端浏览器安全加固 SSDLC过程简介 n安全需求阶段： 分析系统面向的环境，需求和安全成本，定义自身业务系统

45、或产品的安全功能 n安全设计： 通过威胁建模，找到攻击界面，分析和归类安全威胁，漏洞形式，针对安全需求 ，提出缓解和降低安全威胁的措施，同时定义强制的安全策略：包括最小攻击界 面，默认配置打开功能和特权等。 n安全实现： 通过编程规约和培训开发人员，配合源代码审计工具，保证代码都是以良好的安 全习惯得以实施，减少安全问题。 n安全验证： 通过安全测试，确保安全需求定义的安全功能，安全设计中定义的安全策略和威 胁缓解措施都得以实现。同时通过测试尽量找出实现中可定性的安全漏洞（攻击 点），提供给开发团队修复，最大的避免产品发布后的0DAY带来的安全损失。 n安全发布阶段： 指导用户安全部署，提供应

46、急响应计划，实施最终安全复查 安全需求安全需求需求描述需求描述实现阶段实现阶段 身份验证身份验证 启用身份认证功能、口令策略、账号锁定、验证码等功能 在设计阶段提出身份验证的要求，在测试阶段完成有效性验 证 会话管理会话管理 严格会话管理，确保会话的安全性、唯一性、完整性 在设计阶段提出会话管理的开发要求，在测试阶段对会话管 理的可用性进行测试。 访问控制访问控制 程序设计时，需要限制对连接数、内存、文件等资源的访问 设计阶段提出访问控制的开发要求，在测试阶段对可用性等 进行有效性测试。 权限管理权限管理 应用程序需具备账号管理功能，不同账号、不同角色具备不 同权限 在设计阶段提出权限管理的开

47、发要求，在测试阶段验证授权 管理的有效性。 数据保护数据保护 敏感信息、配置文件等重要信息的保存、通信。 在设计阶段提出数据存储与传输的开发要求，在测试阶段验 证授权管理的有效性。 安全审计安全审计 应用程序需支持记录程序启动、关闭事件、应用程序访问事 件、程序出错事件等。 设计阶段提出日志记录的开发要求，测试阶段完成日志审计 有效性、完整性测试。 输入验证输入验证 对客户端提交的输入，后台程序进行严格的检查。实现阶段提出具体要求。 输出处理输出处理 应用程序需要限制输出的内容，特别是敏感信息、错误信息、 用户输入的内容。 实现阶段提出具体要求。 白盒测试、黑白盒测试、黑 盒测试盒测试 需要检

48、查应用程序开发的过程中，特意留下可绕过系统安全 控制的功能或超级口令； 测试阶段提出具体要求。 内存管理内存管理 程序需具有内存管理和控制的功能，限制恶意的使用。实现阶段提出具体要求。 异常处理异常处理 程序在出现异常时，应具有避免信息泄露的措施。实现阶段完成异常管理的要求。 在开发时就应考虑到安全功能安全模块在开发时就应考虑到安全功能安全模块 用户身份认证的强度设计用户身份认证的强度设计 对高价值交易和进入保护区域的用户需要进行对高价值交易和进入保护区域的用户需要进行 重新认证重新认证 认证失败后的处理方式设计认证失败后的处理方式设计 使用强口令策略使用强口令策略 使用图片验证码使用图片验证

49、码 敏感信息加密处理敏感信息加密处理 安全设计阶段：身份认证的设计安全设计阶段：身份认证的设计 安全设计阶段：安全设计阶段：身份认证缺陷导致手机密码被破解身份认证缺陷导致手机密码被破解 限制普通用户对资源的访问；限制普通用户对资源的访问； 应用软件启动权限最小化应用软件启动权限最小化 敏感功能敏感功能IP地址控制地址控制 尽量采用统一的访问控制机制尽量采用统一的访问控制机制 资源请求数量限制资源请求数量限制 在服务器端实现访问控制在服务器端实现访问控制 安全设计阶段：访问控制设计安全设计阶段：访问控制设计 安全设计阶段：资源限制访问安全设计阶段：资源限制访问 限制会话寿命限制会话寿命 确保会话

50、的安全创建确保会话的安全创建 确保会话数据的存储安全确保会话数据的存储安全 确保会话的安全终止确保会话的安全终止 WEB页面应避免跨站请求伪造页面应避免跨站请求伪造 WEB系统确保会话凭证的安全系统确保会话凭证的安全 安全设计阶段：会话管理设计安全设计阶段：会话管理设计 尽量避免明文存储机密信息尽量避免明文存储机密信息 避免在代码中存储机密信息避免在代码中存储机密信息 WEB系统，不要在永久性系统，不要在永久性 cookie 中存储敏感数据中存储敏感数据 WEB系统，不要使用系统，不要使用 HTTP-GET 协议传递敏感数据协议传递敏感数据 避免在配置文件中明文存储数据库连接、口令或密钥避免在

51、配置文件中明文存储数据库连接、口令或密钥 确保通信通道的安全确保通信通道的安全 禁止自创加密算法禁止自创加密算法 安全设计阶段：数据存储与传输的设计安全设计阶段：数据存储与传输的设计 n审计日志应包含时间、内容、来源等关键要素审计日志应包含时间、内容、来源等关键要素 n审计日志应禁止包含用户口令等隐私信息审计日志应禁止包含用户口令等隐私信息 限制对日志数据的访问。应将有权操作日志数据的个人数量减到最 小。只为高度信任的帐户（如管理员）授予访问权限。 支持定期备份和日志数据的分析 n确保日志数据的安全确保日志数据的安全 日志文件禁止存放在WEB网页目录下，防止客户端能够访问到日 志 根据业务平台

52、的重要性，设定日志存储保留的时间。 n防止业务日志欺骗防止业务日志欺骗 安全设计阶段：日志设计安全设计阶段：日志设计 n对所有的输入进行安全验证对所有的输入进行安全验证 p要对所有来源不在可信任范围之内的输入进行验证，包括来自于用户、服务、共享文件、用户和数据库的输入。 p对WEB系统，需要验证HTTP请求消息的全部字段，例如：GET数据和POST数据，COOKIE和Header数据等。 p验证除数据内容外，需限定数据的大小或长度。 p验证所有输出到客户端的内容，输出数据HTML编码. n尽量采用集中验证方法尽量采用集中验证方法 p如条件允许，将输入验证策略作为应用程序设计的核心元素，并采用集

53、中式验证方法，例如，可通过使用共享库中的公 共验证模块。这可确保验证规则的一致性。此外还能减少开发的工作量，且有助于后期的维护工作。 p对于WEB应用，需要编写统一的对于客户端提交数据的验证接口，集中处理输入数据。 n应采用严格的输入验证的方法：应采用严格的输入验证的方法： p验证数据类型，例如预期输入类型为整数，则需要禁止输入英文字符串。 p验证数据长度是否在预期长度范围内。 p验证数值类型是否在预期大小边界内。 p对WEB应用，检查数据是否包含特殊字符，如：、 、 、%、 (、)、 &、+、等。 p尽量使用白名单进行输入检查。 n需在服务器端进行验证需在服务器端进行验证 客户端脚本可以被篡

54、改，如果为了顾全体验，部分重要数据一定要用服务器验证。 n注意规范化问题注意规范化问题 n确保用户没有绕过检查确保用户没有绕过检查 安全实现阶段：输入验证安全实现阶段：输入验证 安全实现阶段：减少不必要输入点安全实现阶段：减少不必要输入点 安全实现阶段：可以任意输入积分安全实现阶段：可以任意输入积分 安全实现阶段：积分验证不允分安全实现阶段：积分验证不允分 安全实现阶段：积分验证不允分安全实现阶段：积分验证不允分 n最小化数据库账号权限最小化数据库账号权限 p应用软件使用的数据库账号必须是普通权限帐户，且只能访问允许的数据库； n严格控制对数据库的查询等操作严格控制对数据库的查询等操作 p应使用支持严格数据类型验证的参数化查询方式（如prepareStatement），使查询和数 据分离。或者，对数据库SQL语句中的来自于不可信任范围内的输入参数进行验证。 n验证数据库返回的数据验证数据库返回的数据 p要求对来自数据库的数据进行验证，确保其格式正确且能够安全的使用，不能盲目的信 赖数据库。 n确保释放数据库资源。确保释放数据库资源。 安全实现阶段：访问数据库安全实现阶段：访问数据库 n限制文件上传限制文件上传 尽量不向