0905

1、xss攻击等其他网站攻击之类的原理，问了能实现攻击最根本的原因是什么
2、拦截器和过滤器的区别和实现原理，拦截的接口方法有哪些
3、单点登录的具体实现

xss攻击等其他网站攻击之类的原理，问了能实现攻击最根本的原因是什么

XSS(Cross Site Scripting)，即跨站脚本攻击：
原理：

1. 攻击者对含有漏洞的服务器发起XSS攻击（注入JS代码）。
2. 诱使受害者打开受到攻击的服务器URL。
3. 受害者在Web浏览器中打开URL，恶意脚本执行。

SQL注入:
Dos攻击&DDos攻击：拒绝服务&分布式拒绝服务

XSS

编码：对用户输入的数据进行HTML Entity编码

用户将数据提交上来的时候进行HTML编码，将相应的符号转换为实体名称再进行下一步的处理。

过滤：移除用户上传的DOM属性，如onerror等，移除用户上传的style节点，script节点，iframe节点等。
1、将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了.
2、过滤或移除特殊的Html标签， 例如:

SQL注入

应对方法

1、参数化SQL：使用参数（Parameter）来给值，在数据库完成SQL指令的编译后，才套用参数运行
2、字符串过滤 、使用正则表达式过滤传入的参数
3、前端js防范SQL注入
4、在数据库中限制用户权限，drop/create/truncate等权限谨慎grant
5、多使用数据库自带的安全参数。如在SQLServer数据库中提供了Parameter这个集合，这个集合提供类型检查和长度验证的功能。如果管理员采用了 Parameter这个集合的话，则用户输入的内容将被视为字符值而不是可执行代码。即使用户输入的内容中含有可执行代码，则数据库也会过滤掉。因为此时数据库只把它当作普通的字符来处理。

Dos攻击&DDos攻击

SYN洪水攻击

属于DoS攻击的一种，它利用TCP协议缺陷，通过发送大量的半连接请求，耗费CPU和内存资源

Smurf攻击：

原理：发送伪装的ICMP数据包，目的地址设为某个网络的广播地址，源地址设为要攻击的目的主机，使所有收到此ICMP数据包的主机都将对目的主机发出一个回应，使被攻击主机在某一段时间内收到 成千上万的数据包
防范：在cisco路由器上配置如下可以防止将包传递到广播地址上；Router(config-if)# no ip directed-broadcast

Ping of Death

原理：这种攻击通过发送大于65536字节的ICMP包使操作系统崩溃；通常不可能发送大于65536个字节的ICMP包，但可以把报文分割成片段，然后在目标主机上重组；最终会导致被攻击目标缓冲区溢 出，引起拒绝服务攻击。有些时候导致telne和http服务停止，有些时候路由器重启。

Connection Flood攻击

TCP建立连接之后很长时间不释放，占用服务器的资源，造成服务器上残余连接(WAIT状态)过多，效率降低，甚至资源耗尽，无法响应其他客户所发起的链接。

HTTP Get攻击

这种攻击主要是针对存在ASP、JSP、PHP、CGI等脚本程序，特征是和服务器建立正常的TCP连接，并不断的向脚本程序提交查询、列表等大量耗费数据库资源的调用。这种攻击的特点是可以绕过普通的防火墙防护，可通过Proxy代理实施攻击，缺点是攻击静态页面的网站效果不佳，会暴露攻击者的lP地址。

UDP DNS Query Flood攻击

发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名。

Dos和DDos攻击
其具体表现方式有以下几种：
1，制造大流量无用数据，造成通往被攻击主机的网络拥塞，使被攻击主机无法正常和外界通信。 UDP泛洪
2，利用被攻击主机提供服务或传输协议上处理重复连接的缺陷，反复高频的发出攻击性的重复服务请求，使被攻击主机无法及时处理其它正常的请求。Smurf攻击、HTTP Get攻击、UDP DNS Query Flood攻击、Connection Flood攻击
3，利用被攻击主机所提供服务程序或传输协议的本身实现缺陷，反复发送畸形的攻击数据引发系统错误的分配大量系统资源，使主机处于挂起状态甚至死机。 Ping of Death、SYN洪水

拦截器和过滤器的区别和实现原理，拦截的接口方法有哪些

区别：过滤器作用于请求到达servlet之前，在spring中也就是在dispacherServlet之前。而拦截器最早只能作用于请求到达servlet之后。
（1）过滤器：
依赖于servlet容器。在实现上基于函数回调，可以对几乎所有请求进行过滤，但是缺点是一个过滤器实例只能在容器初始化时调用一次。使用过滤器的目的是用来做一些过滤操作，获取我们想要获取的数据，比如：在过滤器中修改字符编码；在过滤器中修改HttpServletRequest的一些参数，包括：过滤低俗文字、危险字符等。

public class LoginFilter implements Filter {
 	@Override
	public void destroy() {
		// TODO Auto-generated method stub
	}
 	@Override
	public void doFilter(ServletRequest arg0, ServletResponse arg1, FilterChain arg2)
			throws IOException, ServletException {
		// TODO Auto-generated method stub
		HttpServletRequest request = (HttpServletRequest)arg0;
		HttpServletResponse response = (HttpServletResponse)arg1;
		HttpSession session = request.getSession();
		if(session.getAttribute("LOGIN_USER")==null
				&& request.getRequestURI().indexOf("/system/login") == -1){
			// 没有登录
			response.sendRedirect(request.getContextPath()+"/system/login");
		}else{
			// 已经登录，继续请求下一级资源（继续访问）
			arg2.doFilter(arg0, arg1);
		}
	}
	@Override
	public void init(FilterConfig arg0) throws ServletException {
		// TODO Auto-generated method stub	
	}
}

（2）拦截器：
依赖于web框架，在SpringMVC中就是依赖于SpringMVC框架。在实现上基于java的反射机制，属于面向切面编程（AOP）的一种运用。由于拦截器是基于web框架的调用，因此可以使用Spring的依赖注入（DI）进行一些业务操作，同时一个拦截器实例在一个controller生命周期之内可以多次调用。但是缺点是只能对controller请求进行拦截，对其他的一些比如直接访问静态资源的请求则没办法进行拦截处理。

public class LoginInterceptor implements HandlerInterceptor {
	@Override
	public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object arg2) throws Exception {
		// 在拦截点执行前拦截，如果返回false执行拦截 返回true则不执
		HttpSession session = request.getSession();
		//String uri = request.getRequestURI(); // 获取登录的uri，这个是不进行拦截的
		//if(session.getAttribute("LOGIN_USER")!=null || uri.indexOf("system/login")!=-1) {// 说明登录成功 或者 执行登录功能			
		if(session.getAttribute("LOGIN_USER")!=null) {
			// 登录成功不拦截
			return true;
		}else {
			// 拦截后进入登录页面
			response.sendRedirect(request.getContextPath()+"/system/login");
			return false;
		}
	}
	@Override
	public void postHandle(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, ModelAndView arg3)
			throws Exception {
		// 该方法在action执行后，生成视图前执行。在这里，我们有机会修改视图层数据。
	}
	@Override
	public void afterCompletion(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, Exception arg3)
			throws Exception {
		// 最后执行，通常用于释放资源，处理异常
	}
	
	
}

单点登录的具体实现

单系统登录机制

cookie、session、sessionId
单系统的限制：cookie携带会话id在浏览器与服务器之间维护会话状态。但cookie是有限制的，这个限制就是cookie的域（通常对应网站的域名），浏览器发送http请求时会自动携带与该域匹配的cookie，而不是所有cookie。子域名共享顶级域名的cookie。

多系统

子域名cookie共享完成单点登录
既然这样，为什么不将web应用群中所有子系统的域名统一在一个顶级域名下，例如“*.baidu.com”，然后将它们的cookie域设置为“baidu.com”，这种做法理论上是可以的，甚至早期很多多系统登录就采用这种同域名共享cookie的方式。
然而，可行并不代表好，共享cookie的方式存在众多局限。
首先，应用群域名得统一。
其次，应用群各系统使用的技术（至少是web服务器）要相同，不然cookie的key值（tomcat为JSESSIONID）不同，无法维持会话，共享cookie的方式是无法实现跨语言技术平台登录的，比如java、php、.net系统之间。
第三，cookie本身不安全。
除上面之外，如果我们在session存放的是User对象，那么我们使用全局cookie共享JSESSIONID值，每一个子域名就可以访问同一个session，登录成功后保存一个user对象，注销后就移除这个user对象。session中的user对象必须先序列化保存到redis中，并且每次访问的时候，都需要去redis中取出session，并且重新序列化成user对象。这样会造成额外的消耗。

sso认证中心
redis实现