SQLXMLCRLF注入攻击.docVIP

注入的原则： 违背了：数据与代码分离原则； 注入的条件： 用户能够控制数据的输入； 代码拼凑了用户输入的数据，把数据当做代码执行了； 防御原则： 牢记：数据与代码分离原则； 在拼凑发生的地方进行安全检查； SQL注入 1.SQL注入的典型例子： Var ShipCity; ShipCity = Request.form(“ShipCity”); Var sql = “select*from ordersTable where ShipCity = ‘”+ShipCity+”’ ”; 变量ShipCity的值由用户提交，在正常情况下，假如用户输入“Ken”，那么SQL语句会执行如下： select*from ordersTable where ShipCity = ‘Ken’ 但是假如用户输入一段有语义的SQL语句，比如： Ken’;drop table OrdersTable-- 那么，SQL语句在实际执行时会如下： select*from ordersTable where ShipCity = ‘Ken’;drop table OrdersTable--’ 原本正常执行的查询语句，现在变成了查询完后，再执行一个drop表的操作，而这个操作，就是用户构造了恶意数据的结果。 在SQL注入的过程中，Web服务器的错误回显需要关闭。因为攻击者在利用错误回显中提供的信息有时候更加方便了攻击者进行注入。 SQL盲注： 最常见的盲注验证方法是，构造简单的条件语句，根据返回页面是否发生变化，来判断SQL语句是否得到执行。 比如，一个应用的URL如下： /items.php?id=2 执行的SQL语句为： Select title,description,body from items where id=2 如果攻击者构造如下的条件语句： /items.php?id=2 and 1=2 实际执行的SQL语句就会变成： Select title,description,body from items where id=2 and 1=2 因为“and 1=2”永远是一个假命题，所以这条SQL语句的”and“条件永远无法成立。判断是否会返回空页面或者错误信息； 要达到盲注还需要再次验证and 1=1成立；/items.php?id=2 and 1=1 如果返回正常，说明and条件成立，此时可以判断id参数存在SQL注入漏洞 正确防御SQL注入 使用预编译语句 一般来说，预防SQL注入的最佳方式，就是使用预编译语句，绑定变量 Java： String custname = request.getParameter(“customerName”); String query = “select account_balance from user_data where user_name = ? ”； PreparedStatement pstmt connection.prepareStatement(query); pstmt.setString(1,custname); Resultset results = pstmt.executeQuery(); 使用预编译的SQL语句，SQL语句的语义不会发生改变。在SQL语句中，变量用？表示，攻击者无法改变SQL的结构，在上面的例子中，即使攻击者插入类似于tom’ or ‘1’=’1 的字符串，也只会将此字符串当做username来查询。 使用存储过程 除了使用预编译语句外，我们还可以使用安全的存储过程对抗SQL注入。使用存储过程的效果和使用预编译语句译类似，其区别就是存储过程需要先将SQL语句定义在数据库中。但需要注意的是，存储过程中也可能会存在注入问题，因此应该尽量避免在存储过程内使用动态的SQL语句。如果无法避免，则应该使用严格的输入过滤或者是编码函数来处理用户的输入数据。 如：Java中调用存储过程的例子，其中sp_getAccountBalance是预先在数据中定义好的存储过程。 String custname = request.getParameter(“customerName”); Try { CallableStatement cs = connection.prepareCall(“{call sp_getAccountBalance(?)}”); cs.setString(1,custname); ResultSet results = cs.executeQuery(); } Catch(SQLEeception se) { } 有时候无法使用预编译语句或者存储过程，需要通过输入过滤和编码等方法解决。 检查数据类型 这个就是对不