当前位置：首页 > news >正文

web网络安全

news 文章来源：https://blog.csdn.net/H_shaohui/article/details/134930079 2025/4/4 14:14:40

web安全

一，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不可以？

CSRF（Cross-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 1=1，此时，此时后端程序的执行的SQL语句为：

SELECT * FROM users WHERE username = "archer2017" AND password = "anywords" OR 1=1;

这样无论输入什么样的密码，都会要绕过验证，如果更验证一些，构造密码为 anywords" OR 1=1;DROP TABLE users ，那么整个表都将被删除，执行SQL如下:

SELECT * FROM users WHERE username = "archer2017" AND password = "anywords" OR 1=1;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();

预编译语句需要数据库支持，不过目前主流的关系型数据库如 MySQL，PostgreSQL都支持预编译语句。

如果不可避免地使用 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 中的过滤器，可以参考（TODO）XSS 一节。