本文目录一览：
web前端和web安全有联系吗
1、web安全主要是针对网站、数据库这一类的互联网网站攻击行为的防御。
2、前端、后端、数据库、 *** 等,与Web安全都有关系
csrf的具体含义
Cross-site request forgery:跨站请求伪造，也被称成为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
示例和特性
« ‹ › »
CSRF攻击通过在授权用户访问的页面中包含链接或者脚本的方式工作。例如：一个网站用户Bob可能正在浏览聊天论坛，而同时另一个用户Alice 也在此论坛中，并且后刚刚发布了一个具有Bob银行链接的图片消息。设想一下，Alice编写了一个在Bob的银行站点上进行取款的form提交的链接，并将此链接作为图片tag。如果Bob的银行在cookie中保存他的授权信息，并且此cookie没有过期，那么当Bob的浏览器尝试装载图片时将提交这个取款form和他的cookie，这样在没经Bob同意的情况下便授权了这次事务。
CSRF是一种依赖web浏览器的、被混淆过的 *** 人攻击（deputy attack）。在上面银行示例中的 *** 人是Bob的web浏览器，它被混淆后误将Bob的授权直接交给了Alice使用。
下面是CSRF的常见特性：
依靠用户标识危害网站
利用网站对用户标识的信任
欺骗用户的浏览器发送HTTP请求给目标站点
风险在于那些通过基于受信任的输入form和对特定行为无需授权的已认证的用户来执行某些行为的web应用。已经通过被保存在用户浏览器中的cookie进行认证的用户将在完全无知的情况下发送HTTP请求到那个信任他的站点，进而进行用户不愿做的行为。
使用图片的CSRF攻击常常出现在 *** 论坛中，因为那里允许用户发布图片而不能使用JavaScript。
防范措施
« ‹ › »
对于web站点，将持久化的授权 *** （例如cookie或者HTTP授权）切换为瞬时的授权 *** （在每个form中提供隐藏field），这将帮助网站防止这些攻击。一种类似的方式是在form中包含秘密信息、用户指定的代号作为cookie之外的验证。
另一个可选的 *** 是“双提交”cookie。此 *** 只工作于Ajax请求，但它能够作为无需改变大量form的全局修正 *** 。如果某个授权的 cookie在form post之前正被JavaScript代码读取，那么限制跨域规则将被应用。如果服务器需要在Post请求体或者URL中包含授权cookie的请求，那么这个请求必须来自于受信任的域，因为其它域是不能从信任域读取cookie的。
与通常的信任想法相反，使用Post代替Get *** 并不能提供卓有成效的保护。因为JavaScript能使用伪造的POST请求。尽管如此，那些导致对安全产生“副作用”的请求应该总使用Post方式发送。Post方式不会在web服务器和 *** 服务器日志中留下数据尾巴，然而Get方式却会留下数据尾巴。
尽管CSRF是web应用的基本问题，而不是用户的问题，但用户能够在缺乏安全设计的网站上保护他们的帐户：通过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie。
影响CSRF的因素
«‹ › »
CSRF攻击依赖下面的假定：
攻击者了解受害者所在的站点
攻击者的目标站点具有持久化授权cookie或者受害者具有当前会话cookie
目标站点没有对用户在网站行为的第二授权
外部链接
css安全问题
随着前端技术的发展,安全问题已经从服务器悄然来到了每一个用户的的面前，盗取用户数据, 制造恶意的可以自我复制的蠕虫代码,让病毒在用户间传播,使服务器当掉. 更有甚者可能会在用户不知觉得情况下,让用户成为攻击者,这绝对不是骇人听闻。富客户端的应用越来越广，前端的安全问题也随之增多,今天就简单介绍下一些常见的攻击方式和预防攻击办法。
常见攻击
XSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入的恶意html代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。但是随着前端技术的不断进步富客户端的应用越来越多，这方面的问题越来越受关注。举个简单例子 ： 假如你现在是sns站点上一个用户，发布信息的功能存在漏洞可以执行js 你在 此刻输入一个 恶意脚本，那么当前所有看到你新信息的人的浏览器都会执行这个脚本弹出提示框 （很爽吧 弹出广告 ：）），如果你做一些更为激进行为呢 后果难以想象。
CSRF(Cross Site Request Forgery)，跨站点伪造请求。顾名思义就是 通过伪造连接请求在用户不知情的情况下，让用户以自己的身份来完成攻击者需要达到的一些目的。csrf 的攻击不同于xss csrf 需要被攻击者的主动行为触发。这样听来似乎是有“被钓鱼”的嫌疑哈哈。
多窗口浏览器这这方面似乎是有助纣为虐的嫌疑，因为打开的新窗口是具有当前所有会话的，如果是单浏览器窗口类似ie6 就不会存在这样的问题，因为每个窗口都是一个独立的进程。举个简单例子 ： 你正在玩白社会， 看到有人发了一个连接，你点击过去，然后这个连接里面伪造了一个送礼物的表单，这仅仅是一个简单的例子，问题可见一般。
cookie劫持，通过获取页面的权限，在页面中写一个简单的到恶意站点的请求，并携带用户的cookie 获取cookie后通过cookie 就可以直以被盗用户的身份登录站点。这就是cookie 劫持。举个简单例子： 某人写了一篇很有意思的日志，然后分享给大家，很多人都点击查看并且分享了该日志，一切似乎都很正常，然而写日志的人却另有用心，在日志中偷偷隐藏了一个对站外的请求,那么所有看过这片日志的人都会在不知情的情况下把自己的cookie 发送给了 某人，那么他可以通过任意一个人的cookie 来登录这个人的账户。
我们该怎么做？
大致可以分为两类 1 一般用户 2网站开发人员。
首先我们来说说做为一个一般的web产品使用者，很多时候我们是被动的，是在不知情的情况下被利用的。那么我们可以：
1 对于安全级别较高的web应用访问 需要打开一个独立浏览器窗口。
2 对于陌生人发布的链接更好也是复制然后在新开的窗口中打开，当然更好的办法就是无视 – -。
对于开发人员来说我们得从相对详细的一些角度来分析：
对于xss 攻击 特点是攻击者的代码必须能获取用户浏览器端的执行权限，那么代码是从哪里来的呢，想要杜绝此类攻击出现 其实可以在入口 和出口 进行严格的过滤，这样的双保险应当说99% 的类似问题就被我们解决掉了，另外的1% 是那些蹩脚的浏览器带来的后遗症，相信在未来这种问题会越来越少的。
这里我对xss漏洞的形式作了一些整理
恶意代码值被作为某一标签的内容显示 （如果输入的是html 则html会被解析）例如你输入用户名 更新后用户名会显示到页面中的某一个标签内 如果你输入的是
popper.w＜script src="hack.js" type="text/javajscript"＞＜/script＞
那么如果不做过滤直接显示到页面， 会引进一个第三方的js 代码并且会执行。
策略：在不需要html输入的地方对html 标签 及一些特殊字符( ” ＜ ＞ 等等 )做过滤，将其转化为不被浏览器解释执行的字符
恶意代码被作为某一标签的属性显示（通过用 “ 将属性截断来开辟新的属性 或恶意 *** ） 这种情况往往是是开发人员为了实现功能可能会在某些dom标签上记录一些用户输入的信息例如你输入的用户名 会在页面中的标签中以 title 的形式出现 这时候 如果 你输入的是精心设计的内容 那么 看看 这个
＜a title="popper.w" onclick="alert(1)"＞popper.w" onclick="alert(1)＜/a＞
这里我实际上输入的内容是“popper.w” onclick=”alert(1)”，当然你可以在上边写更多的内容。
策略：对属性中可能存在截断的一些字符进行过滤 属性本身存在的 单引号和双引号都需要进行转码。
恶意代码被作为html代码本身显示 (常见的html编辑器) 这种情况存在的问题最多，不再这里举例子了。
策略：更好对用户输入的html 标签及标签属性做白名单过滤，也可以对一些存在漏洞的标签和属性进行专门过滤。
恶意代码被作为一段json字符串显示 （通过 变量截断 创造新的 恶意的js 变量 甚至是可执行的代码） 这个问题的关键是用户输入的信息可能会成为页面中js 代码的一部分。
策略：对属性中可能存在截断的一些字符进行过滤 属性本身存在的 单引号和双引号都需要进行转码。
对于crsf 和cookie 劫持
特点 隐蔽性比较高 有些时候是先利用xss 漏洞 然后再做 欺骗的
策略
通过 referer、token 或者 验证码 来检测用户提交。
尽量不要在页面的链接中暴漏任何与用户唯一号（用户id）有关的信息。
对于用户修改 删除 提交的操作更好都使用post 操作 。
避免全站通用的cookie 严格的设置cookie的域。
ok 就写到这里~
上边讲的都是一些比较常见的安全问题，主要是从js hack 方面来讲的，随着前端技术的不断发展进步，更多的安全问题可能会展现在我们面，对于开发者来说大多数的问题是可以在开发阶段避免的，所以可怕的不是hack 可怕的是我们对自己的产品安全的松懈
关于XSS,CSRF等
。。。。了解XSS得了解 javascript.. 额 看pkav.net 里面有很多大牛··
可以解释一下黑客入侵计算机数据库背后的原理。
之一步信息收集（敏感目录文件、whois信息、旁注、端口开放、iis几、）
第二部漏洞挖掘（web应用指纹、漏洞有那些xss、CSRF、XSIO、SQL、任何文件读取、上传、之类的）
第三步漏洞利用（目的思考、利用漏洞拿到相关权限、然后提权）
再之后就是提权拿服务器、然后创建隐藏账户、然后擦痕迹、
什么是 CSRF攻击？
，即在某个恶意站点的页面上，促使访问者请求你的网站的某个 URL（通常会用 POST 数据方式），从而达到改变服务器端数据的目的。这一类攻击依赖于你的网页中的表单，脆弱的表单很容易受到攻击。对于你网站中的访问者而言，可能会受到以下攻击： * 在你的网站之外记录受攻击者的日志（比如：Slashdot）； * 修改受攻击者在你的网站的设置（比如：Google）； * 修改你的硬件防火墙； * 使用受攻击者的登录信息在你的网站中发表评论或留言； * 将资金转移到另一个用户帐号中。 CSRF 攻击的典型是那些使用 cookie 记录登录信息的网站，但对于一些允许某个 IP 地址访问的页面（如内部网），这一类攻击也会奏效。 CSRF 攻击通常会使用到 JavaScript（但不仅限于 JavaScript）实现跨站点自动提交表单－－表单数据可以隐藏，提交按钮可以伪装成链接或滚动条。 * 确定那些接受可改变服务器数据的 CGI 只接受 POST 参数，不接受 GET 参数，一些服务器端语言默认同时接受两种方式提交过来的参数； * 确定表单提交处理的是你自己的表单，可以使用一个隐藏字段中存放MD5字符串，此字符串是将登录 cookie 数据与服务器端存放的密钥进行 MD5 之后的结果，只有这个 MD5 字符串正确时才接受表单数据； * 另外还可以增加一个更为严格的 *** ：在表单中增加一个时间戳的隐藏字段，并将其包含到 hash 字符串中，如果时间戳超过某个时间，则认为表单已过期。当表单过期时，给出一个 *** 可以让用户重新提交表单，比如将用户之前填写的数据依旧放入表单中，但使用一个新的 hash 字符串。 一个PHP的表单例子，表单代码：?php$key = y8s4Z7m2; //MD5加密密钥$time = time(); //当前时间 $hash = md5($time.$key); //hash 字符串?form method="post" action="comment.php" pYour name: input type="text" name="person_name" //p pComment: /textarea name="comment" rows="10" cols="60"/textarea/p input type="hidden" name="time" value="?php echo $time; ?" / input type="hidden" name="hash" value="?php echo $hash; ?" / pinput type="submit" name="comment" value="Submit Comment" //p/form表单提交之后的 comment.php 后台处理程序代码：?php$key = y8s4Z7m2; //密钥，与上面的一致 $expire = 1800; //表单过期时间：半小时 $my_hash = md5($_POST[time].$key); //正确的 hash 字符串 if ($my_hash != $_POST[hash]) //hash 字符串不正确 die(非法表单提交。); if (time() - $_POST[time] $expire) { //表单已经过期，生成新的时间戳和 hash 字符串，显示表单让用户重新提交。（此处省略）//….}//表单验证通过，可以接受表单提交的数据，并进行其它操作。 //….?