这是我参与「第五届青训营」伴学笔记创作活动的第11天。
前言
作为一个目前练习时长两年半的Java程序员，虽然“黑产”对于我来说是一个陌生的“世界”，但是所谓黑产在某些层面也是利用业务漏洞去牟利，所以在一个业务体系中，安全部门有自己的职责，作为开发人员我们也应当尽可能地“安全开发”，从而避免出现业务漏洞而给“黑产”可乘之机。
安全开发
我知道“安全开发”这个岗位和我所做的软件开发还是有区别的，因此这里有点标题党的嫌疑（hahahaha）,但是我主要是想分享下以我目前有限的经验可以做的笔记。
1.SQL注入
这个在我们作为Java程序员学到Java Web阶段就已经接触到的名词，想必大家都已经很熟悉，即使你不是Java程序员，你应该也有所耳闻。
举一个简单的例子，我们现在有个登录需求，就是发送一个HTTP请求，而这个请求最终执行的SQL代码如下：
select * from table where username = 'xxxx' and password = 'xxxx'
而有心人通过抓包到了这个请求，然后修改了请求参数，最终这个请求执行的SQL代码变成了如下：
select * from table where username = 'xxxx' and password = 'xxxx' or 1 = 1
那么即使用户名和密码错误的情况下，这个sql也是执行成功了，并返回了正确的响应参数，使得可以跳过登录过程直接登入。
当然了，这个东西很早了，现在开发框架发展得非常完备，我们在持久层也就是DAO层常用的MyBatis框架已经不会发生SQL注入问题了，它是通过预编译解决的。而预编译这个过程怎么执行的？
听我细细道来，首先，我们在编写sql的xml文件里所有的动态参数都会使用#{}包裹，在执行时，mybatis会将#{}替换为？,然后将带有占位符？的sql模板发送到MySQL服务器，由服务器对此无参数的SQL进行编译后，将编译结果缓存，然后直接执行带有真实参数的sql。
通过使用预编译，在这之后注入的参数将不再进行SQL编译。也就是说其后注入进来的参数系统将不再认为它是一条SQL的语句，而默认它是一个参数。
因此，SQL注入的问题基本不需要再担心。
2.开发漏洞
这个就我目前的程度来说，能想到的也就是因为疏忽造成的逻辑不严谨，从而使得业务有了漏洞。当系统大了之后，有漏洞是在所难免的，即使在实际生产项目中，有着牢固的代码审计制度，依然会出现这种情况，比如今天直播课中的2018年某银行的那个漏洞。因此，这个问题依然值得我们所有开发人员去重视和研究。
小结
今天的课程挺有意义，时间虽短，但是让我看到了一个新的领域-黑灰产监控与防御，了解到了一些很有意思的东西,以后可能会多去看看这方面的东西，对自己开发还是很有帮助的，扩宽了知识面。
