首先，我要抱怨一下补天（自己公司的算了别太狠了），一个超级简单的漏洞还要审核那么多细节，竟然说我细节不全不通过，也是服了。好吧，不多说了。
记录一下一次奇葩渗透中遇到的两个问题，好奇怪还都是主流漏洞的SQLI一个，XSS一个。还是增加了很多见识。
第一个问题SQLI：
今天在测试参数时候发现返回的是json，报错信息处理了，也就没太在意，认为没有回显，爆不出数据，算是没有注入。结果Burpsuite的结果赤裸裸的红叹号，大写SQL Injection亮瞎了我的狗眼。
结构是这样的：我测试的是
1 https://a.b.c.d/xxx.php?parameter=10'
结果返回的是json，在这个json中惊奇的发现，SQL Syntax字样。原来，服务器本身再次发起了一个请求：
1 https://127.0.0.1/yyy.php?id=10'
我的参数被传递进去之后拼接了SQL语句，然后，神奇的是，第二个请求的响应报文被完整的放在json中返回给了我，而且第二个：
没有处理报错，没有过滤，没有预编译。
没有处理报错，没有过滤，没有预编译。
没有处理报错，没有过滤，没有预编译。
于是赶紧跑下SQLmap，果断爆出了数据。
1 python sqlmap.py -l ./sqlinjection.txt -p parameter --batch
结果就出了数据，当然另外一个类似的情况虽然有报错，但没有注入出数据。
反思点：
渗透角度
/*一个站点内部可能会有新的请求会拼接你的参数，而且没有处理报错，没有过滤，没有预编译，所以，不要看到一两个参数没有注入，就不做参数SQL注入的测试了。*/
防御角度
/*内部请求也需要做好输入输出过滤，屏蔽报错信息，使用预编译方式执行SQL语句。*/
第二个问题XSS的：
这个原理很简单，原来POST的请求，使用GET去访问，污染参数，返回时，污染的参数带有简单的payload:
<img src=1 src=alert(1)>
这个payload被返回到页面，JS语句执行。但是我突然发现，刚刚打开火狐浏览器时候第一次打开OK，再刷新啥的就返回json被火狐解析了。经过请教高人指点，发现是Content-Type字段不一样，而不一样的原因在于Cookie。
刚刚打开时后不知道什么原因没有带着cookie（不知道为啥，第二次就有cookie了，当然cookie不对也能起效）
两次返回不同：所以第一次执行，第二次失败了
1 Content-Type：text/html #第一次 2 Content-Type：application/json #第二次
反思点：
渗透角度
/*不登录时候访问一些页面，尤其使用GET传递参数（无论原先是POST还是GET）有时候也能发现惊喜*/
防御角度
/*对于未登录直接访问的一些报错要处理，无论登录未登录输入输出要过滤特殊字符，不要妄想使用其他方式规避过滤，就可以防御住XSS*/
/*对于框架本身存在的问题要予以修正，及时关闭调试模式，避免因为调试报错信息导致出现问题*/
/*内部请求或者二次请求的返回的具体信息，如必须要返回给用户，则应处理过滤掉敏感信息后写入响应报文*/