属于web中使用的安全协议.docVIP

PAGE  PAGE 25 属于web中使用的安全协议 篇一：web应用的安全防范 Web数据安全 sql注入 所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令. SQL注入成因： 我们对表单数据处理时(特别是文本框)、以及Url传递参数是经常会产生例如 userName=xxx；id=xxx的语句，这一类语句经常被我们传入到后台的一句SQL语句进行编译 如select * from USER u where u.username = ‘aaa’ and u.password =xxx 的语句 当我们用参数拼接的方式构造此类SQL语句时。一旦黑客们在前台文本框或URL填上 Aaa’ or 1=1 一旦这个参数传入后代中 这一句SQL 就会成立在假设该人了解们系统的表结构或某些表的名称。甚至可以在后面加入删除表或数据的语句。后果不堪设想 SQL注入的防范： 1、永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和 双-进行转换等 2、尽量不要使用拼装SQL的方式进行数据库操作。Java可以采用预编译的方式也可有效的防止SQL注入，或者使用一些持久层框架。 3、没有必要不要使用管理员权限连接数据库 4、对于异常信息不要暴漏给用户。防止不法分子利用异常测试表结构 XSS跨站攻击 XSS攻击：跨站脚本攻击（Cross Site Scripting），为不和层叠样式表（Cascading Style Sheets， CSS）的缩写混淆。故将跨站脚本攻击缩写为XSS。XSS是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。 XSS攻击原理以及频发区域： Web应用给用户与用户之间提供了一个良好的交互平台。如论坛可以让人们在网页上交流信息。但这也成为一些居心不良的黑客们的有利攻击点。比如一个黑客在某某留言版中写下如下代码〈/script〉〈script〉alert(‘test’)〈/script〉 那么如果我们没有对用户在留言板中的输入做任何校验时。这段脚本将被展现到所有浏览过这留言版的用户。 当然这段脚本是毫无意义的。只是弹出了一个提示框而已。但如果我们用 window.location.href=xxx;这种类似脚本既可以实现简单的跨站攻击，在弹出页面就可以做黑客任意想做的事情。因为这个页面是黑客随意编写的木马页。 频发区域：留言板。个性签名。论坛帖子、标题、邮箱邮件和一些可以提交到后台的错误日志信息等等。 跨站攻击的防范 和SQL注入防御一样，XSS攻击也是利用了Web页面的编写疏忽，所以还有一种方法就是从Web应用开发的角度来避免： 步骤1、对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。 步骤2、实现Session标记（session tokens）、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。 步骤3、确认接收的的内容被妥善的规范化，仅包含最小的、安全的Tag（没有javascript），去掉任何对远程内容的引用（尤其是样式表和javascript），使用HTTP only的cookie。 当然，如上操作将会降低Web业务系统的可用性，用户仅能输入少量的制定字符，人与系统间的交互被降到极致，仅适用于信息发布型站点。并且考虑到很少有Web编码人员受过正规的安全培训，很难做到完全避免页面中的XSS漏洞。 数据传输安全 每一个web应用的请求中都会带有很多信息。诸如表单中的信息、请求参数、主机地址等等、这些信息在传输过程中可能被拦截并加以利用。 目前我们做的web应用程序都是基于网络的应用层。如果我们没有对传输数据进行加密或处理的话攻击者可以从多个层面多数据进行获取 1、 通过url参数获得 这种方式也是最直接最简单的方式。如我们在提交表单时候如果是get方式提交的话我们的url会显示http://xxxxxx?username = xxxamp;password=xxx; 首先可以看到我们的信息暴漏无疑。还有叫攻击者很容易知道我们系统所接受的参数名称。可通过url进行SQL注入等攻击。 2、 表示层或传输层侵入 当然我们操作的只是表示层，有些网络高手还可以以某些手短侵入网络其他层去获取我们的信息。 解决方案 对于第一种来说相对比较容易 1、使用post来提交表单、如需要url传参时参照下2种方法 2、当我们提交的表单货连接在iframe中时。路径会隐藏。