-
完全信赖用户提交的内容
-
在web目录中存放敏感数据
-
后门和调试隐患
-
越权漏洞
-
代码同步安全
-
测试环境保护
-
检测机制层次隐患
-
数据来源安全
XSS又叫CSS (Cross Site Script)跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。
XSS攻击可以分成两种类型：
1.非持久型xss攻击：顾名思义，非持久型xss攻击是一次性的，仅对当次的页面访问产生影响。非持久型xss攻击要求用户访问一个被攻击者篡改后的链接，用户访问该链接时，被植入的攻击脚本被用户游览器执行，从而达到攻击目的。
2.持久型xss攻击：持久型xss，会把攻击者的数据存储在服务器端，攻击行为将伴随着攻击数据一直存在。
解决措施：
WeBlog项目使用Flask框架，结合Jinjia2模板来确保安全性。
Jinja2模板引擎的HTML自动转义系统保护系统免受XSS。
Flask 配置 Jinja2 自动转义所有值，除非显式地指明不转义。这就解决了模板导致的所有 XSS 问题。这是jinja2的特性之一。
HTTP是一种明文传输协议，当浏览器用户与网站进行HTTP链接时，两者之间传输的数据容易被第三者的窥视、窃取和篡改等网络攻击。 随着各种网站安全事件频发，HTTP明文协议已被认定为不安全的传输协议。 谷歌宣布Chrome 68在今年7月发布，并把仍在使用HTTP协议的网站全面标识为“Not Secure”（不安全）。
全站HTTPS更安全，HTTPS主要通过在SSL上传输数据来区分HTTP，确保传输的数据在传输过程中被加密，只有相应站点服务器或用户浏览器接收时才能被解密，HTTPS通过这种方式避免了第三方拦截。同时，HTTPS提供可信的服务器认证，这是一套黑客不能随意篡改的认证信息，使相关用户确定他们正与正确的服务器通信。
没有全站HTTPS的网站，使得一些页面为HTTP，一些页面为HTTPS，当通过HTTP或不安全的CDN服务加载其他资源(例如JS或CSS文件)时网站也存在用户信息暴露的风险，而全站HTTPS是防止这种风险最简单的方法。
解决措施：
WeBlog采用全站HTTPS加密，无论是引用的外部CDN资源还是本地服务器都采用了SSL加密机制。我们申请了TrustAsia TLS ECC CA颁发的证书，并添加到了Nginx上。
接着我们修改了Nginx配置，禁止了http访问，并将http链接地址重定向到https，确保用户访问到HTTPS加密的页面。
SQL注入与XSS攻击类似，SQL注入攻击中以SQL语句作为用户输入，从而达到查询/修改/删除数据的目的。SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写的网站也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。
解决措施：
WeBlog项目使用类似Hibernate的数据映射模型的对象关系映射（ORM）工具——SQLAlchemy。在代码中，我们没有使用原生的SQL语句，而是使用ORM库来实现数据库的增删改查。ORM库是防SQL注入的好手。 当SQLAlchemy接收到字符串进行查询时，在构造SQL语句的时候，会默认使用单引号包裹字符串，如果字符串内含有单引号的话，会使用\进行转义，从而达到过滤单引号的效果。正确地使用SQLAlchemy，使本项目出现SQL注入的情况基本不会出现，因为ORM已经做好了大量的防御措施。
明文存储密码是不可取的，一旦数据库被盗，用户的密码便全部泄露了。
解决措施：
WeBlog项目对密码使用了带salt的md5加密。md5加密算法是不可逆的，也就是说是不能够通过解码来获取源来的字符串的。如果需要验证密码是否正确，需要对待验证的密码进行同样的md5加密，然后和数据库中存放的加密后的结果进行对比。普通的md5加密不够安全，我们通过使用salt对字符串进行加密。具体的做法是：我们随机生成salt，然后和我们要加密的字符串进行拼接，之后再用md5进行加密，然后在拼接上我们刚刚的salt。