典型web安全问题

A.md

典型web安全问题

• SQL注入
• XSS：Cross Site Script，跨站脚本攻击。原本可缩写成CSS，但为了和网页设计中的CSS区分
• CSRF：Cross Site Request Fake，跨站点请求伪造

https://www.keakon.net/2012/12/03/Tornado%E4%BD%BF%E7%94%A8%E7%BB%8F%E9%AA%8C

mysql调优.md

• 给经常用来搜索的字段加索引，也就是那些很多业务场景中都会出现在where和order by下的字段，譬如create_time字段
• 连表查询时，为join字段建索引
• 适当建立一些冗余信息，比如招聘所属商家的名字，招聘录用人数，减少join
• 尽量避免使用null值，因为会占用额外的索引空间且难以优化查询
• 尽量使用timestamp存储时间
• OR改写成IN：OR的效率是n级别，IN的效率是log(n)级别，in的个数建议控制在200以内
• 值分布很稀少的字段不适合建索引，例如”性别”、“状态”、“类型”这种只有两三个值的字段
• 不用外键，不用UNIQUE，不用函数和触发器，这些都由应用保证约束
• 在where条件中不做列运算和非运算，因为任何对列的操作都将导致表扫描，索引的功能发挥不出来
• 使用连表查询替代子查询，特别是IN的字段还是非索引字段
• 列表数据不要select全表，要使用LIMIT来分页
• 读写分离
• 使用explain分析SQL慢的原因，possible_keys 为空的，可以考虑从on或者WHERE语句中选取合适的字段建索引
• 使用慢查询日志监测执行时间长的SQL（log-slow-queries = [slow_query_log_filename] long_query_time = 5）

读懂EXPLAIN

http://www.dev120.com/archives/50

mysql范式

• 第三范式：任何非主属性不依赖于其它非主属性，如学生表中不应该包含公寓描述和公寓地址字段，这两个字段的值虽然依赖学生ID，但仅依赖公寓ID就可决定，存在传递依赖，出现层级数据结构

其他

• 第一范式：属性不可分，即字段不可含有列表和其他复杂结构的数据，如果还有则表明还可以在分。
• 第二范式：表中的属性必须完全依赖于全部主键，而不是仅依赖部分主键就可决定，即不存在一些字段依赖某一个主键，而另一些字段依赖另一个主键；比如在选课表中包含学生姓名和年龄，因为这两个字段的值并不依赖课程ID，仅依赖学生ID就可决定，出现分散依赖，这样不单会造成不必要的冗余，还会造成更新困难。

RESTful回答要点.md

最早的时候，我们只需要 GET 和 POST 方法，POST 方法的引入也只是为了消除 URL 过长，参数隐藏，上传文件的问题，完全和语义无关。接触到 RESTful 之后，我们开始思考 GET 和 POST 的不同语义

1. URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作，3端负责具体的表现
2. URL中只用复数名词，原则上不使用动词
3. HTTP动词来控制资源的状态扭转、定位
4. “资源”是处理的核心，现考虑资源后限定动词
5. “资源”在S／C之间传输的表现形式，通常用JSON，XML传输文本，用JPG，WebP传输图片等
6. HTTP Status Code传递Server的状态信息，和HTTP协议并无二致， 200 表示成功，500 表示Server内部错误
7. 为什么：不需要有显式的前端渲染，只需要一套提供对资源服务的接口
8. 组成
9. URL root：二级域名还是二级路径的选择
10. API版本：可以放在URL里面，也可以用HTTP的Header，依据业务场景
11. URL中的参数用来过滤，有时可以和API路径参数互换
12. GET／HEAD方法幂等，即不改变资源状态

---

PATCH vs PUT

• 简要回答就是：PUT是完整更新，PATCH是部分更新；PATCH方法是新引入的，对PUT方法的补充，用来对已知资源进行局部更新

http://gloveangels.com/restful-http-patch-method/ https://ihower.tw/blog/archives/6483

RESTfull 与HTTP code

• HTTP STATUS: 100 CONTINUE
• RestApiTutorial／http://www.restapitutorial.com/

web安全问题的本质.md

“数据流”、“输入输出”

一切的安全问题都体现在“输入输出”上，一切的安全问题都存在于“数据流”的整个过程中。

web安全问题的本质：输入提交的“特殊数据”，在某个层没处理好，被当作该层的指令，在输出的时候，就会出现相应层的安全问题

精彩举例：

1. 如果在操作系统层上没处理好，比如Linux的Bash环境把“特殊数据”当做指令执行时，就产生了OS命令执行的安全问题，这段“特殊数据”可能长得如下这般： ; rm -rf /;

2. 如果在存储层的数据库中没处理好，数据库的SQL解析引擎把这个“特殊数据”当做指令执行时，就产生SQL注入这样的安全问题，这段“特殊数据”可能长得如下这般： ' union select user, pwd, 1, 2, 3, 4 from users--

3. 如果在Web容器层如nginx中没处理好，nginx把“特殊数据”当做指令执行时，可能会产生远程溢出、DoS等各种安全问题，这段“特殊数据”可能长得如下这般： %c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./%20

4. 如果在Web开发框架或Web应用层中没处理好，把“特殊数据”当做指令执行时，可能会产生远程命令执行的安全问题，这段“特殊数据”可能长得如下这般： eval($_REQUEST['x']);

5. 如果在Web前端层中没处理好，浏览器的JS引擎把“特殊数据”当做指令执行时，可能会产生XSS跨站脚本的安全问题，这段“特殊数据”可能长得如下这般： '"><script>alert(/cos is my hero./)</script>

...

Cookies劫持

• 设置cookie为HttpOnly
• 按照浏览器的UA信息或者是客户端的IP地址来生成一个签名串，保证正确的网络环境
• 每个请求里面加上token，保证用户请求的唯一性。

面试中的linux命令

• 查找文件：find，find /home/ljianhui -user ljianhui
• grep：按行查找文本文件或管道，ls -l | grep -i d
• ps：查看系统进程运行情况；ps aux查看系统所有的进程数据
• netstat -anp：查看端口打开情况