|
| 1 | + |
| 2 | +> 攻击网站的方法有哪些? |
| 3 | +
|
| 4 | +**一是**,**DDOS攻击(分布式拒绝服务)**:利用攻击软件通过大量的机器同时对服务进行攻击,规模大,危害大。 |
| 5 | + |
| 6 | +目前有两种主流的DDOS攻击:**SYN Flood攻击**和**TCP全连接攻击**。 |
| 7 | + |
| 8 | +> - SYN Flood攻击:利用tcp协议的缺陷,发送大量伪造的tcp连接请求,导致被攻击方资源耗尽。出现的原因是:在TCP三次握手过程中,假设用户发送了SYN报文后掉线,那么服务器在发出SYN+ACK是无法收到客户端的ACK报文,这时,服务端是会一直不断的重试并等待一段时间后丢弃这个未完成的连接的,如果有大量的伪造的攻击报文,发送到了服务端,服务端将为了维护一个非常大的半连接队列而消耗过多的CPU时间和内存,这就会导致服务器失去响应。 |
| 9 | +> - TCP全连接攻击:这种攻击是为了绕过防火墙设计的,它能够绕过防火墙,导致服务器有大量的TCP连接,最终导致服务器拒绝服务。 |
| 10 | +
|
| 11 | +**解决SYN Flood攻击的方法** |
| 12 | + |
| 13 | +- 设置SYN timeout时间:SYN timeout时间是指服务端一直不断的重试并等待的这段时间。 |
| 14 | +- 设置SYN cookie,判断是否连续收到某个ip的重复SYN报文,如果是,以后就丢弃这个ip地址的包 |
| 15 | +- 设置SYN cache,先不分配系统资源,现用cache保存半开连接,直到收到正确的ACK在分配资源 |
| 16 | +- 硬件防火墙 |
| 17 | + |
| 18 | +**解决TCP全连接攻击的方法** |
| 19 | + |
| 20 | +- 限制SYN流量 |
| 21 | +- 定期扫描缺陷 |
| 22 | +- 在骨干节点设置防火墙 |
| 23 | +- 有足够的机器可以承受攻击 |
| 24 | +- 过滤不必要的服务和端口 |
| 25 | + |
| 26 | +另外,**Land攻击**,该攻击是利用了TCP三次握手时,通过向一个主机发送一个用于建立连接的TCP SYN报文而实现对目标主机的攻击,这种方式与正常的TCP SYN报文不同的是:Land攻击的报文源ip地址和目标ip地址是一样的,都是目标主机的ip地址。 |
| 27 | + |
| 28 | +由于目标IP地址和源IP地址是一样的,因此,ACK报文就发给了主机本身,如果大量的SYN报文进行发送,目标计算机也不能正常工作。 |
| 29 | + |
| 30 | +**二是**,**XSS攻击(跨站脚本攻击)**,它是指恶意攻击者在web网页中插入恶意html代码,当用户浏览网页时,嵌入其中的html代码会执行,从而达到恶意攻击的目的。 |
| 31 | + |
| 32 | +**三是**,**CSRF攻击(跨站请求伪造)**,攻击者盗用了你的身份,以你的名义发送恶意请求,一般是在你登录了A网站以后,携带A网站的信息,然后请求危险B网站,从而导致。 |
| 33 | + |
| 34 | +对于**CSRF攻击(跨站请求伪造)** 可以使用下列方法进行防御: |
| 35 | +- 用户关闭页面要及时清理cookie |
| 36 | +- 在url后面添加伪随机数 |
| 37 | +- 图片验证码等 |
| 38 | + |
| 39 | +**四是**,**SQL注入**,SQL注入是一种将SQL代码添加到输入参数中,传递到服务器解析并执行的一种攻击手法。 |
| 40 | + |
| 41 | +**SQL注入攻击**是输入参数未经过滤,然后直接拼接到SQL语句当中解析,执行达到预想之外的一种行为,称之为SQL注入攻击。 |
| 42 | + |
| 43 | +常见的sql注入,有下列几种: |
| 44 | +- 数字注入 |
| 45 | + |
| 46 | +例如,查询的sql语句为:`SELECT * FROM user WHERE id = 1`,正常是没有问题的,如果我们进行sql注入,写成`SELECT * FROM user WHERE id = 1 or 1=1`,那么,这个语句永远都是成立的,这就有了问题,也就是sql注入。 |
| 47 | + |
| 48 | +- 字符串注入 |
| 49 | + |
| 50 | +字符串注入是因为注释的原因,导致sql错误的被执行,例如字符`#`、`--`。 |
| 51 | + |
| 52 | +例如,`SELECT * FROM user WHERE username = 'sihai'#'ADN password = '123456'`,这个sql语句'#'后面都被注释掉了,相当于`SELECT * FROM user WHERE username = 'sihai' `。 |
| 53 | + |
| 54 | +这种情况我们在mybatis中也是会存在的,所以在服务端写sql时,需要特别注意此类情况。 |
| 55 | + |
| 56 | +该如何防范此类问题呢? |
| 57 | +- 严格检查输入变量的类型和格式,也就是对相关传入的参数进行验证,尽可能降低风险。 |
| 58 | +- 过滤和转义特殊字符。 |
| 59 | +- 利用mysql的预编译机制,在Java中mybatis也是有预编译的方法的,所以可以采用这种方式避免。 |
| 60 | + |
| 61 | +> mybatis中的 # 与 $ 区别? |
| 62 | +
|
| 63 | +这个问题在面试中时常可能被问到,其实,面试官可能一想考考你对mybatis的熟悉程度,二是,想考考你对sql注入的理解。 |
| 64 | + |
| 65 | +我们都知道,mybatis中的动态sql经常会用到这两个符号。 |
| 66 | + |
| 67 | +在动态 SQL 解析阶段, #{ } 和 ${ } 会有不同的表现: |
| 68 | +- #{ } 解析为一个 JDBC 预编译语句(prepared statement)的参数标记符。 |
| 69 | +- ${ } 仅仅为一个纯碎的 string 替换,在动态 SQL 解析阶段将会进行变量替换。 |
| 70 | + |
| 71 | +例如,`select * from user where name = #{name};`会解析为`select * from user where name = ?;`,而`select * from user where name = ${name};`如果我们传递参数"sihai"会解析为`select * from user where name = "sihai"`。 |
| 72 | + |
| 73 | +因此,**${ } 的变量的替换阶段是在动态 SQL 解析阶段,而 #{ }的变量的替换是在 DBMS 中**。 |
| 74 | + |
| 75 | +由上也可得,**尽量使用`#{ }`,可以防止sql注入,除非表名作为变量时,才使用`${ }`。** |
| 76 | + |
| 77 | + |
| 78 | +> session的原理 |
| 79 | +
|
| 80 | +Session是一种可以存储在内存、文件或者数据库中的键值对。 |
| 81 | + |
| 82 | +在程序需要为客户端创建一个请求的session时,服务器会先检查客户端的请求里是否包含一个session的标识,这个标识通常称为session id,如果已经存在,说明已经创建了session,就可以直接使用;如果不存在,则需要服务端重新创建一个session。 |
| 83 | + |
| 84 | +浏览器存储session的方式有三种: |
| 85 | +- 使用Cookie存储,这是常见的方式,”记住我“的功能就是这种方式实现的。 |
| 86 | +- Url重写,这种方式是直接把session id附加在url路径的后面,例如:www.baidu.com?sessionid=xxx。 |
| 87 | +- 在页面表单中增加隐藏域。 |
| 88 | + |
| 89 | +#### session什么时候创建的呢 |
| 90 | + |
| 91 | +这个其实很简单,一般都是服务端在需要的时候使用某种方式进行创建,而不同语言的创建方式都是不一样的。 |
| 92 | + |
| 93 | +#### session什么时候删除? |
| 94 | + |
| 95 | +删除的时机很难说,但你不需要的时候就可以调用服务端的相关api进行删除,例如,注销登录时,我们就可以对用户session进行删除。 |
| 96 | + |
| 97 | +> Cookie的相关原理 |
| 98 | +
|
| 99 | +在程序中,会话跟踪是很重要的事情。理论上,一个用户的所有请求操作都应该属于同一个会话,而另一个用户的所有请求操作则应该属于另一个会话,二者不能混淆。例如,用户A在超市购买的任何商品都应该放在A的购物车内,不论是用户A什么时间购买的,这都是属于同一个会话的,不能放入用户B或用户C的购物车内,这不属于同一个会话。 |
| 100 | + |
| 101 | + |
| 102 | + |
| 103 | +而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕,客户端与服务器端的连接就会关闭,再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内,当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话,必须引入一种机制。 |
| 104 | + |
| 105 | +Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前,基本上所有的网站都采用Cookie来跟踪会话。 |
| 106 | + |
| 107 | +#### Cookie属性项 |
| 108 | + |
| 109 | +|属性名 |描述| |
| 110 | +|-----|-----| |
| 111 | +|String name|该Cookie的名称。Cookie一旦创建,名称便不可更改 |
| 112 | +|Object value|该Cookie的值。如果值为Unicode字符,需要为字符编码。如果值为二进制数据,则需要使用BASE64编码 |
| 113 | +|int maxAge|该Cookie失效的时间,单位秒。如果为正数,则该Cookie在maxAge秒之后失效。如果为负数,该Cookie为临时Cookie,关闭浏览器即失效,浏览器也不会以任何形式保存该Cookie。如果为0,表示删除该Cookie。默认为–1 |
| 114 | +|boolean secure|该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS,SSL等,在网络上传输数据之前先将数据加密。默认为false |
| 115 | +|String path|该Cookie的使用路径。如果设置为“/sessionWeb/”,则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”,则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/” |
| 116 | +|String domain|可以访问该Cookie的域名。如果设置为“.google.com”,则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.” |
| 117 | +|String comment|该Cookie的用处说明。浏览器显示Cookie信息的时候显示该说明 |
| 118 | +|int version|该Cookie使用的版本号。0表示遵循Netscape的Cookie规范,1表示遵循W3C的RFC 2109规范 |
| 119 | + |
| 120 | +#### Cookie的有效期 |
| 121 | + |
| 122 | +Cookie的maxAge决定着Cookie的有效期,单位为秒(Second)。 |
| 123 | + |
| 124 | +- 如果maxAge属性为正数,则表示该Cookie会在maxAge秒之后自动失效。浏览器会将maxAge为正数的Cookie持久化,即写到对应的Cookie文件中。无论客户关闭了浏览器还是电脑,只要还在maxAge秒之前,登录网站时该Cookie仍然有效。 |
| 125 | +- 如果maxAge为负数,则表示该Cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效,关闭窗口后该Cookie即失效。maxAge为负数的Cookie,为临时性Cookie,不会被持久化,不会被写到Cookie文件中。Cookie信息保存在浏览器内存中,因此关闭浏览器该Cookie就消失了。Cookie默认的maxAge值为–1。 |
| 126 | +- 如果maxAge为0,则表示删除该Cookie。Cookie机制没有提供删除Cookie的方法,因此通过设置该Cookie即时失效实现删除Cookie的效果。 |
| 127 | + |
| 128 | +具体的操作方法每种语言都不一样,可以根据不同语言进行设置。 |
| 129 | + |
| 130 | +#### Cookie的修改和删除 |
| 131 | + |
| 132 | +Cookie不提供修改、删除的方法。如果要修改某个Cookie,只需要新建一个同名的Cookie,添加到response中覆盖原来的Cookie。 |
| 133 | + |
| 134 | +如果要删除某个Cookie,只需要新建一个同名的Cookie,并将maxAge设置为0。 |
| 135 | + |
| 136 | +#### Cookie跨域问题 |
| 137 | + |
| 138 | +Cookie是不可以跨域名的,隐私安全机制禁止网站非法获取其他网站的Cookie。 |
| 139 | + |
| 140 | +同一个一级域名下的两个二级域名也不能交互使用Cookie,比如a1.baidu.com和a2.baidu.com,因为二者的域名不完全相同。如果想要baidu.com名下的二级域名都可以使用该Cookie,需要设置Cookie的domain参数为.baidu.com,这样a1.baidu.com和a2.baidu.com就能访问同一个cookie。 |
| 141 | + |
| 142 | +#### Cookie被浏览器禁用怎么办? |
| 143 | + |
| 144 | +我们浏览网站的时候,很多网址会让我们选择是否可以使用cookie,如果你选择了禁用是否就没有方法了呢? |
| 145 | + |
| 146 | +- Url重写,这种方式是直接把session id附加在url路径的后面,例如:www.java1000.com?sessionid=xxx。 |
| 147 | +- 在页面表单中增加隐藏域。 |
| 148 | + |
| 149 | +> Cookie和Session的区别? |
| 150 | +
|
| 151 | +- 存储位置不同。Cookie存储在客户端,Session一般位于服务器上。 |
| 152 | +- Session相对更加安全。Cookie是存在于客户端,对客户是可见的;而Session存储在服务端,对客户是透明的,不存在信息安全问题。因此,我们使用Cookie时,是不建议存储敏感信息的。 |
| 153 | +- Session会消耗服务器资源,会为每个用户分配一个session,所以,当用户量很大时,会消耗大量的服务器内存;而Cookie存在于客户端,不占用服务器资源,如果用户量大,并发高,Cookie是很好的选择。 |
| 154 | +- Cookie的容量有限制,单个Cookie的容量不能超过4KB,而session没有限制。 |
| 155 | + |
| 156 | +> Session和Cache的区别? |
| 157 | +
|
| 158 | +- Session是单用户的会话状态。当用户访问网站时,就会对其生成一个Seesion,session的sessionid会保存到cookie中,用于后续会话。 |
| 159 | +- Cache是服务端的缓存,是对项目的所有用户都是共享的,因为采用数据库的方式有些场景的接口响应不够好,所以采用缓存来进行优化,比如使用redis进行优化,提高访问速度。 |
| 160 | + |
| 161 | +> 经典面试题:在浏览器输入url到响应结果的整个过程,会用到哪些协议? |
| 162 | +
|
| 163 | +整个请求的流程是这样的。 |
| 164 | +- 输入url,进行域名解析,DNS协议解析域名获得IP |
| 165 | +- 依据IP地址浏览器向服务器发送HTTP请求,使用TCP协议与服务器建立连接 |
| 166 | +- 连接建立时要发送数据,发送数据在网络层使用IP协议 |
| 167 | +- 期间IP数据包在路由器间路由选择使用OPSF协议 |
| 168 | +- 路由器与服务器通信,需要将IP转换为MAC地址,使用ARP协议 |
| 169 | +- 随即服务器处理请求,发回一个HTML响应,浏览器使用HTTP协议显示HTML页面 |
0 commit comments