开工大吉|策马扬鞭,跃启新程!
2026-02-25
浙江省委宣传部副部长、省委网信办主任赵磊:守正创新 辩证施策 全力推动网络生态治理工作迈上新台阶
2026-02-10
美创产品全面入围中直机关2025年网络设备框架协议采购项目
2026-02-04
连续5年!美创再获中国网络安全产业联盟“先进会员单位”表彰
2026-01-21
每周安全速递³⁷¹ | 勒索软件攻击导致心理健康机构超11万人数据泄露
2026-01-06
存储域
数据库加密 诺亚防勒索访问域
数据库防水坝 数据库防火墙 数据库安全审计 动态脱敏流动域
静态脱敏 数据水印 API审计 API防控 医疗防统方运维服务
数据库运维服务 中间件运维服务 国产信创改造服务 驻场运维服务 供数服务安全咨询服务
数据出境安全治理服务 数据安全能力评估认证服务 数据安全风险评估服务 数据安全治理咨询服务 数据分类分级咨询服务 个人信息风险评估服务 数据安全检查服务这个系列我将带大家从零了解XSS攻击及防御的知识,所以今天我们先简单得了解与之相关的其他必备知识,也就是web前端基础!
1 web前端基础
1.1 HTML
HTML是用来描述网页的一种语言
• HTML 指的是超文本标记语言 (Hyper Text Markup Language)
• HTML 不是一种编程语言,而是一种标记语言 (markup language)
• 标记语言是一套标记标签 (markup tag)
• HTML 使用标记标签来描述网页
HTML标记标签通常被称为 HTML 标签(HTML tag)
• HTML 标签是由尖括号包围的关键词,比如
• HTML 标签通常是成对出现的,比如 和
• 标签对中的第一个标签是开始标签,第二个标签是结束标签
• 开始和结束标签也被称为开放标签和闭合标签
下面是HTML的实例:
1.2 CSS
CSS定义如何显示 HTML 元素
下面是一段添加了CSS的HTML代码,运行结果出现了拥有CSS的样式的结果。
Hello World!
这个段落采用CSS样式化。
1.3 Javascript
依靠HTML和CSS就可以做出很漂亮的网页,那Javascript是干什么的呢?
如果将网页形容成是一个人,HTML是驱赶,CSS是衣服,那么Javascript就是思维,而思维决定了行为。
下面我们来写段代码:
请输入数字。如果输入值不是数字,浏览器会弹出提示框。
在输入框输入字母:
就按Javascript代码写的,弹出了错误信息:
是不是感觉就有了灵魂,有了思维。
我们来总结下,HTML+CSS+JS= 网页
• HTML 定义了网页的原始内容
• CSS 描述了网页的原始布局
• JavaScript决定了网页的行为
1.4 Cookie
1.4.1 什么是Cookie
Cookie意为“甜饼”,是由W3C组织提出,最早由Netscape社区发展的一种机制。目前Cookie已经成为标准,几乎所有的浏览器都支持cookie。
由于HTTP是一种无状态的协议,服务器单从网络连接上无从知道客户身份。怎么办呢?就给客户端们颁发一个通行证吧,每人一个,无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。
Cookie实际上是一小段的文本信息。客户端请求服务器,如果服务器需要记录该用户状态,就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时,浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie,以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
1.4.2 Js 操作 Cookie
一般来说,只有服务器操作 Cookie 才能保证一些必要的安全。但有时候,可能需要前端来增删改查 Cookie, 这个时候咱们的主角出现了——HttpOnly。
HttpOnly 是包含在 Set-Cookie HTTP 响应头文件中的附加标志。生成 cookie 时使用 HttpOnly 标志有助于降低客户端脚本访问受保护 cookie 的风险(如果浏览器支持)。
这个意思就是说,如果某一个 Cookie 选项被设置成 HttpOnly = true 的话,那此 Cookie 只能通过服务器端修改,Js 是操作不了的,对于 document.cookie 来说是透明的。话不多说,直接上图:
以 Google 翻译为例子,初次打开时,Cookie 里面是这样的HttpOnly有好多√,这个对勾表明这条记录是 HttpOnly = true 的,对于 Js,你是拿不到的。我们来试一下:
果不其然,Js 获取 Cookie 的时候就会跳过 HttpOnly = true 的 Cookie 记录。当然,既然拿不到,那就跟别说删改了。
1.4.3 为什么 cookie 不安全
最大的原因是因为它存储在浏览器端(用户本地),一些别有用心的人能够通过浏览器截获 cookie(脚本、利用工具抓取等)。
1.4.3.1 cookie 欺骗
一些别有用心的人不需要知道这个 cookie 的具体含义,只需要将这个 cookie 向服务器提交(模拟身份验证),身份验证通过之后,就可以冒充被窃取 cookie 对应用户来访问网站,甚至获取到用户的隐私信息,对于用户的隐私造成非常严重的危害,这种方式就叫做 cookie 欺骗。
1.4.3.2 cookie 截获
cookie 以纯文本的形式在浏览器和服务器之间传递,在 web 通信时极容易被非法用户截获和利用。非法用户截获 cookie 后,在 cookie 的有效时间内重新发放给服务器,那么这个非法用户就拥有了这个合法用户的所有权限。
1.4.3.3 Flash的内部代码隐患
Flash 中有一个 getURL() 函数,Flash 利用它自动打开指定的页面。那么这个就意味着,你在观看 Flash 动画时,在 Flash 的内部可以悄无声息的打开一个极小的不易发现的包含特殊操作的页面,可以是木马,可以向远端输入当前 cookie 或者用户信息,这是非常危险的,由于这个是 Flash 内部的操作,所以网站无法禁止,要想避免,尽量打开本地防火墙以及访问正规网站。
1.5 Session
1.5.1 Session机制
由于cookie存在一定的安全缺陷,因此开发者开始使用一种更为安全的认证方式——Session。
Session的中文意思是会话,其实就是访问者从到达特定主页到离开的那段时间,在这个过程中,每个访问者都会得到一个单独的Session,当浏览器或进程关闭之后,Session也就消失了。
在Session机制中,客户端和服务端通过标识符来识别用户身份和维持会话,但这个标识符也会有被其他人利用的可能。
Session和Cookie的最大区别在于:Session是保存在服务器的内存里面,而Cookie保存于浏览器或者客户端文件里面的。
1.5.2 借助Cookie实现Session机制
Session的运行依赖Sessionid,而 Sessionid 是存在Cookie中的,也就是说,如果浏览器禁用了Cookie,同时 Session也会失效(Session可以使用HTML5中的其他功能实现,但现在绝大部分网站都还是依赖Cookie)
1.6 同源策略
1.6.1 什么是同源策略及如何分辨
同源策略是Web应用安全模型中的一个重要概念,它是浏览器最核心最基本的安全功能
在同源策略下,如果没有特别的授权,那么只有当两个Web页面具有相同的源时,才被允许读写对方的资源。
而相同的源则指的是:协议相同、域名相同、端口相同(IE除外)
同学们可以做个小测试加深下印象
对比域名:http://www.example.com/dir/page.html
1.6.2 非同源限制
1.6.2.1 Cookie 跨域
Cookie 是服务器写入浏览器的一小段信息,只有同源的网页才能共享。
两个网页一级域名相同,只是二级域名不同,浏览器允许通过设置 document.domain 共享 Cookie.
例如:
A 网页地址为 http://A1.example.com
B 网页地址为 http://B1.example.com
A 网页与B网页 一级域名相同,二级域名不同,所以可以通过设置document.domain='example.com';
来实现跨域访问cookie
在A页面存在
document.cookie="cookieName=cookieValue";
那么在B页面可以通过
val allCookie=document.cookie获取到A网页保存的cookie
注意,这种方法只适用于 Cookie 和 iframe 窗口,LocalStorage 和 IndexDB 无法通过这种方法,规避同源政策
另外,服务器也可以在设置 Cookie 的时候,指定 Cookie 的所属域名为一级域名,比如 .example.com
1.6.2.2 DOM 跨域
如果两个网页不同源,就无法拿到对方的 DOM。典型的例子是 iframe 窗口和 window.open 方法打开的窗口,它们与父窗口无法通信。
同理:
如果两个窗口一级域名相同,只是二级域名不同,那么设置上一节介绍的document.domain属性,就同样可以规避同源政策,拿到DOM。
而对于完全不同源的网站解决办法有以下三:
1.片段识别符(fragment identifier)
2.window.name
3.跨文档通信API(Cross-document messaging)
1.片段标识符
片段标识符指的是,URL 的 # 号后面的部分,比如 http://example.com/x.html#fragment 的 #fragment。如果只是改变片段标识符,页面不会重新刷新
//父窗口可以将需要传递的信息保存到子窗口的片段标识符中
var src = originURL + '#' + data;
document.getElementById('myIFrame').src = src;
//子窗口通过监听hashchange事件得到信息
window.onhashchange = checkMessage();
function checkMessage() {
var message = window.location.hash;
//同理子窗口也可以将需要传递的信息保存到父窗口的片段标识符中
parent.location.href= target + "#" + hash;
2.window.name
浏览器窗口有 window.name 属性。这个属性的最大特点是,无论是否同源,只要在同一个窗口里,前一个网页设置了这个属性,后一个网页可以读取它。
父窗口先打开一个子窗口,载入一个不同源的网页,该网页将信息写入window.name属性
window.name = data;
接着,子窗口跳回一个与主窗口同域的网址
location = 'http://parent.url.com/xxx.html';
然后,主窗口就可以读取子窗口的window.name了
var data = document.getElementById('myFrame').contentWindow.name;
这种方法的优点是,window.name 容量很大,可以放置非常长的字符串;缺点是必须监听子窗口 window.name 属性的变化,影响网页性能。
3.window.postMessage
HTML5 为了解决这个问题,引入跨文档通信 API(Cross-document messaging)
这个API为window对象新增了一个window.postMessage方法,允许跨窗口通信,不论这两个窗口是否同源
父窗口http://aaa.com向子窗口http://bbb.com发消息
var popup = window.open('http://bbb.com', 'title');
popup.postMessage('Hello World!', 'http://bbb.com');
//postMessage方法的第一个参数是具体的信息内容,第二个参数是接收消息的窗口的源(origin),即"协议 + 域名 + 端口"。也可以设为*,表示不限制域名,向所有窗口发送。
子窗口向父窗口发送消息的写法类似
window.opener.postMessage('Nice to see you', 'http://aaa.com');
父窗口和子窗口都可以通过message事件,监听对方的消息
window.addEventListener('message', function(e) {
console.log(e.data);
},false);
//message事件的事件对象event,提供以下三个属性
event.source:发送消息的窗口
event.origin: 消息发向的网址
event.data: 消息内容
1.6.2.3 Ajax 跨域请求
同源政策规定,AJAX 请求只能发给同源的网址,否则就报错。
ajax跨域解决:
1.JSONP
2.WebSocket
3.CORS
4.架设代理服务器
1.JSONP
JSONP 是服务器与客户端跨源通信的常用方法。最大特点就是简单适用,老式浏览器全部支持,服务器改造非常小。
• 在 js 中不能够跨域访问数据,但是在 js 中可以跨域请求 js 片段(js 代码)
• 所以我们将数据包装在一个 js 片段内,这样我们可以跨域获取该 js 片段内的数据
可以使用 ajax 请求包含 json 数据的 js 片段,然后在回调访问内立即执行响应的 js 片段,从而取出包含在内的 json 数据
jsonp 的原理:通过 script 标签引入一个 js 文件,这个 js 文件载入成功后会执行我们在 url 参数中指定的函数,并且会把我们需要的 json 数据作为参数传入,有种回调的味道!
2. websocket
WebSocket 是一种通信协议,使用 ws://(非加密)和 wss://(加密)作为协议前缀。该协议不实行同源政策,只要服务器支持,就可以通过它进行跨源通信。
以下为websocket协议请求头
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
我们可以发现该协议请求头里面存在如下信息:Origin: http://example.com, 即该请求来源于哪个域
正是因为有了 Origin 这个字段,所以 WebSocket 才没有实行同源政策。因为服务器可以根据这个字段,判断是否许可本次通信。如果该域名在白名单内,服务器就会做出如下回应
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
3. CROS(Cross-Origin-Resource-Sharing)跨域资源共享
它是 W3C 标准,是跨源 AJAX 请求的根本解决方法。相比 JSONP 只能发 GET 请求,CORS 允许任何类型的请求。
CORS 需要浏览器和服务器同时支持。目前,所有浏览器都支持该功能,IE 浏览器不能低于 IE10。
整个 CORS 通信过程,都是浏览器自动完成,不需要用户参与。对于开发者来说,CORS 通信与同源的 AJAX 通信没有差别,代码完全一样。浏览器一旦发现 AJAX 请求跨源,就会自动添加一些附加的头信息,有时还会多出一次附加的请求,但用户不会有感觉。
因此,实现 CORS 通信的关键是服务器。只要服务器实现了 CORS 接口,就可以跨源通信。
这周我们就讲到这里,把大致需要了解的前端知识过了一遍,下周开始XSS攻击!