cookie

1 目标 爬取牛客网上关于《数据结构》的试题。 试题链接 进入网页可以看到，如果选择《数据结构》的某个知识点组卷，一次最多只能出30题。 因此，想法就是用程序一次将30题全部爬下。随后生成新的试卷再进行爬虫。 2 实现思路 2.1 最初思路 访问第一题的url 爬取试题 找到下一题的url后，重复1.2操作，直到爬完30题 很遗憾，打开devtools看试题页的元素，发现必须先登录才能有试题页面， 因此问题来到了登录上。 用devtools看登录过程，没有相应的帐号、密码信息，因此无法用帐号密码post方式登录。但是注意到登录页有cookie，如下图右侧，故可采用cookie方式登录。 另外发现该页面有全部试题的url，因此新的方案为 2.2 新思路 通过cookie访问第一题url，获得全部试题的url 依次访问每题的url，爬取 3 代码 # -*- coding: utf-8 -* """ 目标，爬取全部的题目以及答案 1. 利用cookie访问网页，记录全部的题目id并记录在内存中 需要把标签的属性记下来 2. 依次访问这些题目的网页，爬取问题选项和答案 3. 存储到本地文件 """ import requests from lxml import etree import re def pageid ( url , cookie ) : headers = { 'User

转自 https://www.cnblogs.com/lihuidu/p/6495247.html 1、基于Cookie的单点登录的回顾 基于Cookie的单点登录核心原理： 将用户名密码加密之后存于Cookie中，之后访问网站时在过滤器（filter）中校验用户权限，如果没有权限则从Cookie中取出用户名密码进行登录，让用户从某种意义上觉得只登录了一次。 该方式缺点就是多次传送用户名密码，增加被盗风险，以及不能跨域。同时www.qiandu.com与mail.qiandu.com同时拥有登录逻辑的代码，如果涉及到修改操作，则需要修改两处。 2、统一认证中心方案原理 在生活中我们也有类似的相关生活经验，例如你去食堂吃饭，食堂打饭的阿姨（www.qiandu.com）告诉你，不收现金。并且告诉你，你去门口找换票的（passport.com）换小票。于是你换完票之后，再去找食堂阿姨，食堂阿姨拿着你的票，问门口换票的，这个票是真的吗？换票的说，是真的，于是给你打饭了。 基于上述生活中的场景，我们将基于Cookie的单点登录改良以后的方案如下： 经过分析，Cookie单点登录认证太过于分散，每个网站都持有一份登陆认证代码。于是我们将认证统一化，形成一个独立的服务。当我们需要登录操作时，则重定向到统一认证中心http://passport.com。于是乎整个流程就如上图所示： 第一步

转自： https://www.cnblogs.com/lihuidu/p/6495247.html 1、基于Cookie的单点登录的回顾 基于Cookie的单点登录核心原理： 将用户名密码加密之后存于Cookie中，之后访问网站时在过滤器（filter）中校验用户权限，如果没有权限则从Cookie中取出用户名密码进行登录，让用户从某种意义上觉得只登录了一次。 该方式缺点就是多次传送用户名密码，增加被盗风险，以及不能跨域。同时www.qiandu.com与mail.qiandu.com同时拥有登录逻辑的代码，如果涉及到修改操作，则需要修改两处。 2、统一认证中心方案原理 在生活中我们也有类似的相关生活经验，例如你去食堂吃饭，食堂打饭的阿姨（www.qiandu.com）告诉你，不收现金。并且告诉你，你去门口找换票的（passport.com）换小票。于是你换完票之后，再去找食堂阿姨，食堂阿姨拿着你的票，问门口换票的，这个票是真的吗？换票的说，是真的，于是给你打饭了。 基于上述生活中的场景，我们将基于Cookie的单点登录改良以后的方案如下： 经过分析，Cookie单点登录认证太过于分散，每个网站都持有一份登陆认证代码。于是我们将认证统一化，形成一个独立的服务。当我们需要登录操作时，则重定向到统一认证中心http://passport.com。于是乎整个流程就如上图所示： 第一步

1、基于Cookie的单点登录 　　 原理： 　　将用户名密码加密智斗存于Cookie中，之后访问网站时在过滤器校验用户权限，如果没有权限则从Cookie中取出用户名密码进行登录，让用户觉得 只登录了一次。 2、统一认证中心方案原理 　　在生活中我们也有类似的相关生活经验，例如你去食堂吃饭，食堂打饭的阿姨（www.qiandu.com）告诉你，不收现金。并且告诉你，你去门口找换票的（passport.com）换小票。于是你换完票之后，再去找食堂阿姨，食堂阿姨拿着你的票，问门口换票的，这个票是真的吗？换票的说，是真的，于是给你打饭了。 　　基于上述生活中的场景，基于Cookie的单点登录改良以后的方案如下： 　　　　 　　经过分析，Cookie单点登录认证太过于分散，每个网站都持有一份登录认证代码。于是将认证统一化，形成一个独立的法务。 当需要登录操作时，则重定向到同意认证中心http://passport.com。整个流程如上图所示： 　　1：用户访问www.qiandu.com。过滤器判断用户是否登录，没有登录，则重定向（302）到网站http://passport.com。 　　2、重定向到passport.com。输入用户名密码。passport.com将用户登录的信息记录到服务器的session中。 　　3、passport.com给浏览器发送一个特殊凭证

介绍 CSRF（Cross Site Request Forgery, 跨站请求伪造）是一种网络的攻击方式，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF CSRF漏洞是因为web应用程序在用户进行敏感操作时，如修改账号密码、添加账号、转账等，没有校验表单token或者http请求头中的referer值，从而导致恶意攻击者利用普通用户的身份（cookie）完成攻击行为 原理 用户访问a网址，在a网址的cookie有效期内，又访问了b网址，b网站里含有对a网址进行恶意请求的代码，由于此时a网址的cookie没有过期，所以对不会对这个恶意请求进行过滤 一次CSRF攻击的过程中，受害者需要依次完成两个步骤 1.登录受信任网站A，并在本地生成Cookie 2.在A的cookie存活期内，访问危险网站B CSRF高危触发点 论坛交流、用户中心、反馈留言、交易管理、后台管理 漏洞出现在论坛交流，或者是个人用户中心和反馈留言这些常规的功能处，会造成隐私的泄露； 漏洞发生在交易管理功能的页面，此时可以进行一些类似转账或者是购买物品的操作，那么用户的资产便会存在安全隐患； 漏洞发生在后台管理的功能处，则会威胁到网站本身的安全性。 漏洞危害 CSRF漏洞会导致受害人在不知情的情况下向论坛发帖子、订阅邮件列表、网购或股票交易

cookie机制 123 Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些cookies 。 12 具体来说cookie机制采用的是在客户端保持状态的方案。它是在用户端的会话状态的存贮机制，他需要用户打开客户端的cookie支持。cookie的作用就是为了解决HTTP协议无状态的缺陷所作的努力。 1234 正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript也可以生成cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。 12345 cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失

参考地址： https://www.cnblogs.com/xiaozhang2014/p/7750200.html 1. 为什么要有session的出现？ 答：是由于网络中http协议造成的，因为http本身是无状态协议，这样，无法确定你的本次请求和上次请求是不是你发送的。如果要进行类似论坛登陆相关的操作，就实现不了了。 2. session生成方式？ 答：浏览器第一次访问服务器，服务器会创建一个session，然后同时为该session生成一个唯一的会话的key,也就是sessionid，然后，将sessionid及对应的session分别作为key和value保存到缓存中，也可以持久化到数据库中，然后服务器再把sessionid，以cookie的形式发送给客户端。这样浏览器下次再访问时，会直接带着cookie中的sessionid。然后服务器根据sessionid找到对应的session进行匹配； 还有一种是浏览器禁用了cookie或不支持cookie，这种可以通过URL重写的方式发到服务器； 简单来讲，用户访问的时候说他自己是张三，他骗你怎么办？ 那就在服务器端保存张三的信息，给他一个id，让他下次用id访问。 3. 为什么会有token的出现？ 答：首先，session的存储是需要空间的，其次，session的传递一般都是通过cookie来传递的，或者url重写的方式

什么是会话技术 HTTP协议是无状态、无记忆的。多次请求之间，无任何的联系，无法把请求的状态保存下去，即同一用户请求同一网站的不同页面，服务器无法识别是否是同一用户发起的请求。用户无法进行连续的业务逻辑。 在同一台浏览器对服务器的多次请求中，将数据持久化存储的技术，以实现连续的业务逻辑。 会话周期：从打开浏览器，访问一些web资源，直至关闭浏览器为止，这个时间间隔为会话周期。 会话周期结束可能导致某些数据失效。 会话技术分类：按照数据持久化的位置进行区分，如果数据保存在浏览器端,我们称之为cookie技术，如果数据保存在服务器端,我们称之为session技术。 cookie原理 ：我们的cookie数据是保存在浏览器端的,我们每次请求的时候,都会携带这个信息. 这样的话,服务器就认识我们了 ① 我们的浏览器如果是第一次请求服务器, 是没有cookie信息的.这个时候我们的第一次请求没有携带任何cookie信息, 请求发给服务器之后, A脚本会通过 setcookie来给我们设置一个cookie ② 响应的时候会携带设置的cookie信息, 浏览器接收到这个响应之后,会把cookie信息保存在浏览器的cookie区域中 ③ 如果我们再次请求 同一个网站的时候,我们的请求会携带cookie信息. ④ 服务器脚本会通过$_COOKIE来获取 请求携带的cookie

1. 什么 XSS 攻击？如何预防？ 跨站脚本攻击 【存储性（持久型）】 存储型 XSS，也叫持久型 XSS，主要是将 XSS 代码发送到服务器（不管是数据库、内存还是文件系统等。），然后在下次请求页面的时候就不用带上 XSS 代码了。用户输入的带有恶意脚本的数据存储在服务器端。当浏览器请求数据时，服务器返回脚本并执行。 最典型的就是留言板 XSS。 【反射型（非持久型）】 反射型 XSS，也叫非持久型 XSS，把用户输入的数据 “反射” 给浏览器。通常是，用户点击链接或提交表单时，攻击者向用户访问的网站注入恶意脚本。XSS 代码出现在请求 URL 中，作为参数提交到服务器，服务器解析并响应。响应结果中包含 XSS 代码，最后浏览器解析并执行。从概念上可以看出， 反射型 XSS 代码是首先出现在 URL 中的，然后需要服务端解析，最后需要浏览器解析之后 XSS 代码才能够攻击 。 如何预防 ： 内容安全策略 (CSP) 入参字符过滤 出参进行编码 入参长度限制 HttpOnly 阻止 Cookie 劫持攻击 服务器端 Set-Cookie 字段设置 HttpOnly 参数，这样可以避免 Cookie 劫持攻击。这时候，客户端的 Document.cookie API 无法访问带有 HttpOnly 标记的 Cookie, 但可以设置 cookie。 2. 什么是 CSRF 攻击

Tornado 是 FriendFeed 使用的可扩展的非阻塞式 web 服务器及其相关工具的开源版本。这个 Web 框架看起来有些像web.py 或者 Google 的 webapp，不过为了能有效利用非阻塞式服务器环境，这个 Web 框架还包含了一些相关的有用工具 和优化。 Tornado 和现在的主流 Web 服务器框架（包括大多数 Python 的框架）有着明显的区别：它是非阻塞式服务器，而且速度相当快。得利于其 非阻塞的方式和对 epoll 的运用，Tornado 每秒可以处理数以千计的连接，这意味着对于实时 Web 服务来说，Tornado 是一个理想的 Web 框架。我们开发这个 Web 服务器的主要目的就是为了处理 FriendFeed 的实时功能 ——在 FriendFeed 的应用里每一个活动用户都会保持着一个服务器连接。（关于如何扩容 服务器，以处理数以千计的客户端的连接的问题，请参阅 C10K problem 。） pip install tornado 源码安装 https: / / pypi.python.org / packages / source / t / tornado / tornado - 4.3 .tar.gz 一、快速上手 第一步：执行脚本，监听xxxx端口 第二步：浏览器客户端访问 /index --> http://127.0.0