据说，这张被命名为“千万别惹程序员”的经典神图最近又诈尸了，频频出现在微博和朋友圈里受众人膜拜。
说膜拜真的一点不夸张，因为这是一条既有态度又有技术含量的车牌遮挡贴，它牛逼的点在于，当你驾车从电子眼下飞驰而过，你的这个伪车牌被拍下时，这串命令将通过OCR变成文本，然后插入到交警系统的数据库。此时，这个车牌就成了SQL注入，假设它排除万难（或数据库防御能力太次）得以奏效，就可以把存放车牌号的数据库给删掉！
SQL注入是什么鬼？
这是怎么做到的？SQL注入又是什么？按照标准释义，SQL注入就是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力。在这里举一个连大妈都能看得懂的简单例子。
假设一个大妈把自家老公催眠了（别问我是怎么做到的），让他完全按照自己写的纸条内容去市场买菜，纸条上写的内容形式如下：
步行至___区，进入___号摊位，挑选___，付钱后放到菜篮子里。
按照正常指示，一个普通的买菜过程应该是这样的：
步行至A区，进入6号摊位，挑选2个茄子，付钱后放到菜篮子里。
红字部分就是由大妈发出的命令，然后老公就会按照指示，走到A区的6号摊位买2个茄子，付过钱后放进菜篮子。
但是，如果大妈在纸条的空格里填了不正常的值呢？
步行至A区，进入6号摊位，挑选2个茄子然后把其中一个扔到地上，另一个剥开来生吃，边吃边往家里走，并且忽略这张纸条上的其他指示，付钱后放到菜篮子里。
因为此时的老公是被催眠的状态（都说了不要问我怎么做到的…），他会严格按照纸条写的指示去做，所以就会发生他走到A区6号摊位把一个茄子扔地上另一个茄子往嘴里塞的惨状……而因为指示上要求“忽略这张纸条上的其他指示”，所以“付钱后放到菜篮子里”这个部分会被忽略，导致大妈老公在制造完这场混乱之后钱也不给掉头就走……
SQL注入过程
就像大妈告诉她老公要买什么菜，SQL是一种告诉数据库需要做什么的特殊语言。如上图所示，SQL注入之所以发生，是因为我们碰到的是完全一样的问题——一个查询（一系列的指令）会有多个参数（数据）插入其中，而这些参数被当做指令执行从而导致异常。一个恶意的用户可以利用这样的漏洞来让数据库返回所有的用户信息，很显然，这是不对滴！
怎么防御SQL注入？
据2015年数据库漏洞威胁报告显示，2015年SQL注入依旧是漏洞中的主流，80%以上的漏洞都属于SQL注入范畴，利用数据库系统SQL语言漏洞，通过对低权限用户进行升级权限来获取更多数据库内的敏感信息。
如此猖狂的SQL注入怎么防？下面教你一种正确的综合防御姿势。如下图所示，理想的解决思路是在Web应用生命周期的各个阶段做相应的努力。
基于Web生命周期的SQL注入防护法
1开发阶段
在编码阶段需要对输入进行细致的验证，使用静态查询，如使用参数化声明。且遵循“最小权限准则”，即只赋予应用程序完成其功能的最基本权限。以下是关于最小权限的一些建议：
- 不要使用root权限访问数据库；
- 为数据表设定限制的可读/可写权限；
- 慎用数据库存储过程。
2测试阶段
在测试阶段采用以下两种方式确保Web应用程序代码的安全性：第一，采用源代码审核方式，从编程者角度审视代码是否存在漏洞；第二，执行渗透测试，从攻击者角度检查代码的安全性。需要注意的是，尽管完成以上两步，仍不能确保100%的安全，但这两种方法对于确保应用程序质量是必须的。
3产品化阶段
在产品化阶段，Web应用程序已经正常上线，并对外提供服务。但还是会发现Web应用存在安全隐患，此时整改代码对各类组织来说已经不现实了，因为需要付出较大代价。这时，可以部署专用的Web应用防火墙（Web Application Firewall，简称WAF），以大幅提升Web应用的安全等级。
别以为不是技术人员就与你无关
能坚持看到这里的普罗大众，你们值得拥有小编发自肺腑的温馨提醒！
鉴于现在很多网站、软件系统都有可能存在SQL注入的安全漏洞，所以对于用户账号和密码这些重要的敏感信息，大家还是妥善保管为妙，不要偷懒怕忘记就只用同一个账号和秘密通用于所有的注册，更不要把密码与银行卡、QQ的密码设置成一样的。这点提防之心还是要有的，万一泄露了呢？