dede微电影网站模板,合山网络推广,一流的赣州网站建设,山东联通网站备案web安全
一#xff0c;xss
跨站脚本攻击(全称Cross Site Scripting,为和CSS#xff08;层叠样式表#xff09;区分#xff0c;简称为XSS)是指恶意攻击者在Web页面中插入恶意javascript代码#xff08;也可能包含html代码#xff09;#xff0c;当用户浏览网页之时xss
跨站脚本攻击(全称Cross Site Scripting,为和CSS层叠样式表区分简称为XSS)是指恶意攻击者在Web页面中插入恶意javascript代码也可能包含html代码当用户浏览网页之时嵌入其中Web里面的javascript代码会被执行从而达到恶意攻击用户的目的。XSS是攻击客户端最终受害者是用户当然网站管理员也是用户之一。 XSS漏洞通常是通过php的输出函数将javascript代码输出到html页面中通过用户本地浏览器执行的所以xss漏洞关键就是寻找参数未过滤的输出函数。
1.1.危害 1.用户的Cookie被获取其中可能存在Session ID等敏感信息。若服务器端没有做相应防护攻击者可用对应Cookie登陆服务器。 2.攻击者能够在一定限度内记录用户的键盘输入。 3.攻击者通过CSRF等方式以用户身份执行危险操作。 4.XSS蠕虫。 5.获取用户浏览器信息。 6.利用XSS漏洞扫描用户内网。 2.2.防御 1.标签过滤 2.事件过滤 3.敏感字符过滤 4.设置httponly防止Cookie被获取 5.内容安全策略CSP 6.在将不可信数据插入到HTML标签之间时对这些数据进行HTML Entity编码 7.在将不可信数据插入到HTML属性里时对这些数据进行HTML属性编码 8.在将不可信数据插入到SCRIPT里时对这些数据进行SCRIPT编码 9.在将不可信数据插入到Style属性里时对这些数据进行CSS编码
当然如果过过滤不全或者CSP配置错误也可能被绕过。
参考文章https://blog.csdn.net/lady_killer9/article/details/107126005 二CSRF
CSRF (Cross—Site Request Forgery)既跨站点请求伪造也被叫做 XSRF和 XSS 一样也是一种比较常见的 web 攻击。CSRF攻击者会过过构造的第三方页面诱导受害者完成加载或者点击利用受害者的权限以其身份向合法网站发起恶意请求通常用户发生状态改变的请求比如虚拟货币的转账账号信息修改恶意发邮件等等由于具有一定的隐蔽性所以比较防范。 2.1.CSRF 的防范
目前主要有如下几种方式 添加 Referer 域名白名单HTTP 的 Referer 头记录了当前请求的来源页面的URL如果用户是通过浏览器打开的网页一般都会带有这个信息。可以验证 URL 的域名是否在网站允许的白名单呢内如果不在则拒绝请求。这种方式实现比较简单而且可以在web 服务器层统一配置减少了后端开发成本当 Referer 页可以伪造用户浏览器的可靠性也不能完全信赖判断 Referer 可以做为一种辅助手段但不能根治 CSRF。 令牌 (Token )验证令牌验证的方式这是目前方法CSRF的一种普遍方法其原理是在用户正式提交数据更新之前给用户生成一个 token一方面token保存在服务端比如Session 或者缓存中一方面输出请求发生的页面上在用户提交请求时连同token一同提交服务获得接收到请求之后再做token验证token 不存在、或者token不一致或者失效都算作验证失败。token 的生成具有一定的随机性而且是在提交数据的页面生成攻击这往往难于伪造。token 一般作为一个post 字段提交或者作为ajax请求的header信息提交
2.2.为什么token可以防止CSRF攻击cookies不可以
CSRFCross-Site Request Forgery跨站请求伪造攻击是一种利用用户已经在其他网站上登录并保存了相关认证凭证如Cookies的情况下通过恶意网站发起伪造请求的攻击方式。攻击者通过诱使用户访问恶意网站利用已保存的认证凭证执行非法操作例如进行转账、更改密码等。
Token可以防止CSRF攻击的主要原因有以下几点 随机性Token是由服务器生成的随机字符串每次请求都会生成一个新的Token并将其与用户会话相关联。攻击者无法获知这个随机字符串因此无法构造有效的伪造请求。 不自动发送与Cookies不同Token不会自动附加在每个请求中。在需要验证用户身份的请求中服务器会要求客户端主动发送该Token。这样即使攻击者成功伪造了请求但缺少正确的Token服务器会拒绝执行该请求。 防止被窃取Cookies存储在浏览器中容易受到XSS跨站脚本攻击等攻击手段的窃取。而Token通常是存储在HTTP请求头中或作为请求参数发送不会自动附加到每个请求中因此更难以被窃取。
虽然Cookies也可以采取一些措施来减少CSRF攻击的风险如SameSite属性、HttpOnly属性等但这些措施仍然无法完全防止CSRF攻击。相比之下Token通过引入随机性和主动验证的方式提供了更可靠的防护机制。
需要注意的是为了保证Token的安全性开发者需要采取一些措施例如使用HTTPS协议传输、设置适当的Token过期时间、确保Token的随机性和独一性等。只有在正确实施的情况下Token才能有效地防止CSRF攻击。
2.3.为什么Token存储在HTTP请求头中或作为请求参数中就不容易被窃取Cookies存储在浏览器中容易被窃取
Token 存储在 HTTP 请求头或请求参数中相较于存储在浏览器的 Cookies 中更难被窃取的原因主要有以下几点 存储位置不同Cookies 是存储在客户端浏览器中的而 HTTP 请求头或请求参数通常是由服务端返回给客户端然后由客户端发送给服务端的。由于服务端可以采用一些安全措施来保证 Token 的传输过程的安全性例如使用 HTTPS 加密传输因此 Token 存储在 HTTP 请求头或请求参数中更难被窃取。 相对短暂为了确保 Token 的安全性它们通常被设定为相对短暂的有效期一旦过期就需要重新获取。这样即使攻击者窃取到 Token也只能在一段时间内进行恶意操作。相比之下Cookies 可能会存储很长时间具有较高的风险。 不可见性HTTP 请求头或请求参数是不可见的除非通过网络抓包等手段才能获取到其中的信息。而 Cookies 存储在浏览器中可以通过浏览器的开发者工具等手段来查看和修改。
需要注意的是即使 Token 存储在 HTTP 请求头或请求参数中也并不能完全避免被窃取的风险。为了保证 Token 的安全性开发者还需要采取其他一些措施例如确保 Token 的随机性和独一性、设置适当的有效期、限制 Token 的使用范围等。同时开发者还需要对服务端进行认真的安全评估和漏洞扫描及时修复可能存在的安全问题。
参考文章https://coderxing.gitbooks.io/architecture-evolution/content/di-san-pian-ff1a-bu-luo/641-web-an-quan-fang-fan/6412-csrf.html
三SQL
SQL 注入页也是一种常见的 Web 攻击方式主要是利用后端程序的漏洞针对数据库主要是关系型数据库进行攻击。攻击者通常通过输入精心构造的参数绕过服务器端的验证来执行恶意 SQL 语句SQL注入会造成拖库原始数据表被攻击者获取绕过权限验证或者串改、破坏、删除数据。数据往往是一个网站甚至一个公司的生命一但SQL漏洞被攻击者利用通常会产生非常严重的后果对于SQL 注入的防范需要开发者倍加重视。下面通过一个例子来演示SQL注入的攻击过程对于一个登陆验证的请求一般需要通过用户输入的用户名和密码进行查询验证查询SQL 语句如下
SELECT * FROM users WHERE username $username AND password $password;
比如攻击者已知一个用户名archer2017可以构造密码为 anywords OR 11此时此时后端程序的执行的SQL语句为
SELECT * FROM users WHERE username archer2017 AND password anywords OR 11; 这样无论输入什么样的密码都会要绕过验证如果更验证一些构造密码为 anywords OR 11;DROP TABLE users 那么整个表都将被删除执行SQL如下:
SELECT * FROM users WHERE username archer2017 AND password anywords OR 11;DROP TABLE users;3.1.SQL 注入的防范
SQL 注入发生绝大多数情况都是直接使用户输入参数拼装 SQL 语句造成的防范 SQL 注入主要的方式丢失避免直接使用用户输入的数据。
使用预编译语句PreparedStatement一方面可以加速 SQL 的执行一方面可以防止SQL注入。理解 PreparedStatement 防范 SQL 注入的原理先要理解预编译语句的原理如下图所示 TODO重新画
3.2.SQL 语句的编译分为如下几个阶段
基本解析包括SQL语句的语法、语义解析以及对应的表和列是否存在等等。编译将 SQL 语句编译成机器理解客理解的中间代码格式。查询优化编译器在所有的执行方案中选择一个最优的。缓存缓存优化后的执行方案。执行阶段执行最终查询方案并返回给用户数据。
预编译语句指的是在缓存之后在执行阶段的之前的编译后的语句通过占位符来替代查询查询参数。同样的SQL如果参数不同普通的SQL语句每次请求都会进行编译而预编译语句只会编译一次在执行阶段会从缓存中取出预编译语句并将占位符替换成查询参数数据而在这个阶段SQL 语句已经是编译后的语句参数数据只能最为纯数据使用不能作为SQL语句的一部分通过SQL字符串的拼装已经不起作用所以可以避免SQL注入。
Java 代码中使用预编译语句
String query SELECT * FROM users WHERE username ? AND password ?;
PreparedStatement pstmt connection.prepareStatement( query );
pstmt.setString( 1, username);
pstmt.setString( 2, password);
ResultSet results pstmt.executeQuery( );PHP 中使用预编译语句:
$sth $dbh-prepare(SELECT * FROM users WHERE username ? AND password ?);
$sth-bindParam(1, $username, PDO::PARAM_STR, 20);
$sth-bindParam(2, $password, PDO::PARAM_STR, 16);
$sth-execute();预编译语句需要数据库支持不过目前主流的关系型数据库如 MySQLPostgreSQL都支持预编译语句。 如果不可避免地使用 SQL 语句进行拼装可以对用户输入数据进行转移尤其是多单双引号的转义。
Java 中可以使用 Apache Common类库的 StringEscapeUtils 中的方法例如
StringEscapeUtils.escapeSql(sql);StringEscapeUtils.escapeSql 方法在最新版的Apache Common 类库中被移除掉按照官方文档的说法是为了避免引起程序员在处理SQL时的产生误解官方推荐使用与预编译语句而不是拼装字符串的方法。 或者使用 ESAPI OWASP Enterprise Security API是一套开源的企业级的安全过滤组件。
Codec MYSQL_CODEC new MySQLCodec(MySQLCodec.Mode.STANDARD);
String query SELECT * FROM users WHERE username ESAPI.encoder().encodeForSQL(MYSQL_CODEC, username) AND password ESAPI.encoder().encodeForSQL(MYSQL_CODEC, password) ;在 PHP 中如下面方法
$username mysql_real_escape_string($username);//或 addslashes($username)
$password mysql_real_escape_string($password);
$sql SELECT * FROM users WHERE username $username AND password $password;另外除了上述两种方案意外还要用户输入的数据进行校验Java 中可以使用 Apache Commons Validator 类库PHP 中可以使用 filter_var 中的过滤器可以参考TODOXSS 一节。
