SQL注入XSS与CORS攻击原理及防范指南
SQL注入
说到常见的Web安全风险，SQL注入绝对是个“资深元老”。简单来说，它的核心玩法就是在Web表单、查询字符串等用户输入的地方，巧妙地塞入恶意的SQL命令，最终“骗”过服务器去执行它。
免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈
SQL注入攻击的总体思路
任何一次成功的SQL注入，通常都离不开以下几步“标准动作”：
- 第一步，侦察地形。攻击者得先找到存在SQL注入漏洞的输入点，比如一个登录框或者搜索栏。
- 第二步，识别目标。确定后端的服务器类型和具体的数据库种类，比如是MySQL、Oracle还是SQL Server，因为语法和特性各有不同。
- 第三步，精准打击。根据上面摸清的情况，构造出有针对性的注入攻击语句。
SQL注入攻击实例
光说理论可能不够直观，来看一个经典的“万能密码”场景。假设有一个登录界面，需要输入用户名和密码。攻击者完全可以这么输入：
用户名： 'or 1 = 1 -- 密 码：
点击登录后，如果后端没做处理，攻击者就能大摇大摆地进去了。是不是有点匪夷所思？我们拆解一下背后的逻辑。
通常，后端的身份验证SQL语句会是这样写的：
String sql = "select * from user_table where username=' "+userName+" ' and password=' "+password+" '";
当把前面那个“特殊”的用户名和密码（其实密码为空）拼接进去后，这条SQL就变成了：
SELECT * FROM user_table WHERE username=''or 1 = 1 -- and password=''
关键就在这里了。username='' or 1=1 这个条件，因为 1=1 永远为真，所以整个WHERE子句结果也为真。后面那两个连续的减号 --，在SQL里是行注释符，意味着它把后面的 and password='' 整个给注释掉了，完全失去了过滤作用。于是，这条查询总能成功返回用户数据，非法登录就这样发生了。
如何应对
-
参数绑定（预编译）
这是目前公认最有效、最根本的防御手段。它的原理是，使用预编译语句将SQL语句的骨架预先定义好，而用户输入的数据只被当作“参数”传递，不会被解释为SQL代码的一部分。这就从根本上切断了注入的可能。现在主流的技术框架，比如MyBatis，也明显区分了这两种方式：使用
#符号是占位符，相当于预编译，安全；而使用$是直接拼接字符串，风险很高，需要慎用。 - 使用正则表达式过滤传入的参数：作为一种辅助手段，对输入进行严格的格式检查和过滤。
XSS攻击
如果说SQL注入是“骗服务器”，那么XSS（跨站脚本攻击）的核心就是“骗浏览器”。攻击者会想方设法在网页中注入恶意的客户端脚本（最常见的是Ja vaScript），当其他用户浏览这个被“污染”的页面时，嵌入的脚本就会在其浏览器中执行，从而达到盗取信息、会话劫持等目的。
通俗点讲，攻击者就是“教唆”用户的浏览器，去执行一段这个页面上本不该有的代码。
一个典型的例子就是留言板（这属于“持久型XSS”）。留言板的功能很单纯：展示用户留言。正常情况下，大家输入的都是文字。但如果有攻击者留言时输入了这样一句话：
那么，最终生成的页面HTML代码就会包含这行脚本。当下一个用户打开留言板，浏览器加载到这行代码时会怎么处理？它可分辨不出这是善意还是恶意，只会老老实实地执行，弹出一个警示框。页面结构大致会变成这样：
留言板
非持久 XSS攻击
除了上面那种会“永久存储”在服务器上的持久型XSS，还有一种更常见的“反射型XSS”（非持久）。它通常需要诱骗用户点击一个精心构造的链接。
比如，一个正常的消息链接可能是：
//www.test.com/message.php?send=Hello,World！
而一个恶意的链接则可能是：
https://www.test.com/message.php?send=！
当用户点击这个链接，服务器将 send 参数的值（即那段脚本）直接嵌入到返回的页面中，脚本便在用户浏览器里执行了。
XSS问题产生的根源，很大程度上在于过于信任客户端提交的数据。因此，黄金法则就是：永远不要信任用户输入。所有来自客户端的数据，都必须经过严格的检查、过滤或转义处理，才能进行下一步操作。