我是风筝，公众号「古时的风筝」，一个兼具深度与广度的程序员鼓励师，一个本打算写诗却写起了代码的田园码农！
文章会收录在 JavaNewBee 中，更有 Java 后端知识图谱，从小白到大牛要走的路都在里面。
标题有点臭不要脸，有标题党之嫌了，没有黑，只是网站安全性做的太差，我一个初学者随便就搞到了管理员权限。
事情是这样子的，在10年以前，某个月黑风高夜的夜里，虽然这么说有点暴露年龄了，但无所谓，毕竟我也才18而已。我打开电脑，在浏览器中输入我们高中学校的网址，页面很熟悉，很简陋，也没什么设计感，不过学校的网站从来都是这种风格，直到今天依然是这样。
这次访问与以往有些不同，因为我的目的很明确。作为学校的一员，理应为学校做些贡献的，为学校官网找些安全漏洞也算贡献的一种吧（强烈的求生欲）。
之所以选择学校的官网，一来是因为熟悉，先从熟悉的东西下手，一定错不了。二来是因为之前使用网站的时候碰过到一些异常的页面，直接就是异常堆栈直接抛出来。正好那段时间对网络安全比较有兴趣，在研究SQL 注入的时候正好想到在学校官网上碰到的问题好像就存在 SQL 注入的风险。于是，顺理成章，我的第一个目标就锁定了学校官网。
问题就出在一个大概这样的搜索页面，真正的网站已经改版过好多次了，以前的页面找不到了。
当时我在上面随便输入了一些内容，里面含有单引号，然后一点击搜索，页面就直接出现了异常提示，类似于下面这样子的。别惊讶，当时很多网站都是这样的，异常是直接抛出来的，别说以前了，现在也不少。
于是我用那时候刚学会的皮毛知识，加上两个好用的工具，轻松拿到了数据库的数据，其中就包括了管理员的账号、密码，密码还是明文的，你说气人不。
然后通过后台管理员登录页面进入了管理员后台，当然了，只是进去看了看，什么都没碰，而且后台也没什么重要数据，顶多就是一些通知、新闻等数据。
我是怎么做到的呢，不说具体细节了，也确实没什么技术含量，而且时间太长也记不清了，后面就说一下 SQL 注入的原理和具体操作。
什么是 SQL 注入SQL注入，是发生于应用程序与数据库层的安全漏洞。简而言之，是在输入的字符串之中注入SQL指令，在设计不良的程序当中忽略了字符检查，那么这些注入进去的恶意指令就会被数据库服务器误认为是正常的SQL指令而运行，因此遭到破坏或是入侵。
SQL 注入一般发生在用户交互场景中，比如需要用户自已输入信息的输入框，或者下拉选择选项的这种，如果不做好输入内容的过滤，就很可能发生 SQL 注入。
就拿这个登录界面来说，用户名和密码都是你要输入的内容，点击登录按钮之后，会把你输入的值传递到服务端，服务端再到数据库进行查询。
假设后端的查询语句是这样的，不要在乎这是什么语法，只是举个例子。
String sql = "select * from `user` where account={account} and password={password}";正常的情况，比如 account 输入的是一个电话号码 13001980988，密码是 123456，那拼接出的 SQL 语句就是
String sql = "select * from `user` where account='13001980988' and password='123456'";然后，服务端通过数据库连接执行这条语句：
select * from `user` where account='13001980988' and password='123456';最后，数据库正常返回符合条件的记录，代码中再根据结果进行判断，执行后面的逻辑。
不正常的输入SQL 注入就是通过不正常的输入来获取程序开发者意料之外的结果。
什么是不正常的输入呢？
比如我在用户名输入框中输入的内容是这样子的 :13001980988' or 1=1 -- ，密码输入框随便输入什么都无所谓，然后点击登录，传输给后端，后端拼接出来的结果就是这样的：
String sql = "select * from `user` where account='13001980988' or 1=1 --' and password='123456'";然后，服务端通过数据库连接会执行下面这条语句：
select * from `user` where account='13001980988' or 1=1 --' and password='123456'以 MySQL 为例， -- 是 MySQL 中的注释符号，上面的语句中 --后面的相当于是注释内容了，所以最后实际执行的 SQL 语句是这样的：
select * from `user` where account='13001980988' or 1=1