`
javaoldboy
  • 浏览: 70092 次
  • 性别: Icon_minigender_1
  • 来自: 南京
社区版块
存档分类
最新评论

Web开发中的一些安全问题

阅读更多

本文不是教你怎么防御, 是让你知道有这么一回事情。 安全的问题很深入, 知道有这些后,才能深入学习。
1. SQL Injection<SQL注入攻击>
   在Java中, 使用PrepareStatment是不可能产生这样的攻击的, 通常这类攻击产生是由于程序员借助一些API,或者配置文件, 动态的修改SQL语句造成的。 如果程序员不对输入的参数不做检查或者转义编码, 就可能产生SQL攻击。 防范这个问题的最简单的办法是, 不要使用用户输入的参数组装SQL语句。 这可能有点凹口。 实际上这类问题通常发在类似的操作上, 使用like, order by等操作上。 这2个语句最容易产生SQL注入:
  select * from table_a where table_a.col like '%$name$%'
  如果用户输入: ';select * from sys
  组装完SQL后, 变成了
  select * from table_a where table_a.col like '%';select * from sys%'
  所以, 后面的东西变成什么恶意的SQL, 那么问题就来了。 如果是DDL语句,后果自己想。
  例子很多的, 但是, 一个原则, 不要动态的手动组装SQL语句。
2. XSS攻击<跨站脚本>: 攻击者在页面中注入具有恶意js或者html代码,从而完全控制用户浏览器。如果你的web应用必须支持用户提供的HTML,那么应用的安全性将受到灾难性的下滑。但是你还是可以做一些事来保护web站点:确认你接收的HTML内容被妥善地格式化,仅包含最小化的、安全的tag(绝对没有JavaScript),去掉任何对远程内容的引用(尤其是样式表和JavaScript)。
  对于非HTML的输出, 必须使用HTML ESCAPED来转义输出内容。

3.安全控制
  在很多网站上, 有很多UPDATE、 DELETE、INSERT的操作, 但是, 由于程序员的忽略, 这些操作没有限制用户操作权限。
  比如 http://sdh5724.iteye.com/admin/blogs/deleteblog?id=12345
  SQL 写成了 delete from blog where id=12345
  那么有用户把12345 修改为 54321就可能删除别人的文章了。 这个安全因素在非常的网站都存在。从授权角度来来说, 这个SQL写成 delete from blog where id=12345 and memberid='sdh5724' 这样就安全了。
  这个问题的变形是很多的。 开发的时候需要注意。

4. CSRF攻击,伪造客户端请求的一种攻击,CSRF的英文全称是Cross Site Request Forgery,字面上的意思是跨站点伪造请求
主要如下:
1.  没有验证用户http请求的方式 POST 或者 GET,GET请求被合法通过!
2.  没有验证表单来源的唯一性,不能识别是合法的表单提交还是黑客伪造的表单提交! 
这个问题主要是要防止构造一个FORM表单提交,通过为FORM表单增加一个检查字段<session token>.  提交的时候, 确定该session token是否是该用户生产的。 session token可以保存在cache,数据库, 或者sesion中。

大约目前Web攻击就这些类型, 但是都是非常复杂的。 需要仔细的研究才能明白。说的解决办法都是简易的。 如果要一个完全的解决办法,最好咨询安全工程师或者小黑们。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics