Get央求与Post央求的分歧,传敏感数据

图片 7

Get央求与Post央求的分歧,传敏感数据

即选用了 https 也无须通过 query strings 传敏感数据

2017/10/16 · 基本功本领 ·
HTTPS

本文由 伯乐在线 –
xiaoheike
翻译,艾凌风
校稿。未经许可,幸免转发!
立陶宛共和国(Republic of Lithuania)语出处:HttpWatch。应接参预翻译组。

劳动器端的 log 将公开记下完整 url;浏览器上的访谈历史也会公开记下完整
url;Referrer headers 里也忠实记下完全 url,然后在外人家的 GoogleAnalytics 上海展览中心示。

我们平常听到的四个相近难点是:“URL
中的参数是或不是可以高枕而卧地传递到平安网址?”这一个主题材料平常出现在客商看了
HttpWatch 捕获的 HTTPS 乞请后,想清楚还也可以有什么人能够看到这一个多少。

 

举个例子,要是在多少个询问中,使用如下安全的 URL 传递密码字符串:

HttpWatch 能够彰显安全央浼的剧情,因为它与浏览器集成,因而它能够在
HTTPS 请求的 SSL
连接对数码加密在此以前查看数据。图片 1

假若您利用互联网嗅探器查看,举个例子
Network Monitor,对于同三个伸手,你只好够查阅加密现在的数量。在数据包追踪中从不可以看到的网站,标题或内容:

图片 2

你可以信赖 HTTPS 需要是安全的,只要:

  • 未忽视任何SSL证书警报
  • Web 服务器用于运转 SSL 连接的私钥在 Web 服务器自身之外不可用。

因此,在互连网规模,URL 参数是平安的,不过还应该有点别样根据 URL
泄漏数据的不二等秘书技:

  1. URL 存款和储蓄在 Web 服务器日志中–平常种种恳求的黄金年代体化 URL
    都被贮存在在服务器日志中。那意味着 URL
    中的任何敏感数据(比如密码)会以公开情势保留在服务器上。以下是使用查询字符串通过
    HTTPS 发送密码时存款和储蓄在 httpwatch.com 服务器日志中的条款:
    **二零一零-02-20 10:18:27 W3SVC4326 WWW 208.101.31.210 GET
    /Default.htm password=mypassword 443 …
    平常感觉正是是在服务器上,积攒明文密码平素都不是好主见
    2.URLs are stored in the browser history – browsers save URL
    parameters in their history even if the secure pages themselves are
    not cached. Here’s the IE history displaying the URL parameter:
  2. URL 存款和储蓄在浏览器历史记录中–即便安全网页自身未缓存,浏览器也会将
    URL 参数保存在其历史记录中。以下是 IE 的历史记录,展现了 URL
    的倡议参数:图片 3

要是客户创制书签,查询字符串参数也将被储存。

  1. URLReferrer 央浼头中被传送–借使二个时来运转网页使用能源,举例
    javascript,图片也许剖析服务,URL 将通过 Referrer
    乞请头传递到每贰个停放对象。一时,查询字符串参数也许被传送并寄放在第三方站点。在
    HttpWatch 中,你可以见见我们的密码字符串正被发送到
    Google Analytics图片 4

结论

消灭净尽那一个标题亟需两步:

  • 唯有在相对少不了的图景下传递敏感数据。风姿罗曼蒂克旦顾客被验证,最棒使用全部有限生命周期的会话
    ID 来标记它们。

采取会话层级的 cookies 传递消息的优点是:

  • 它们不会积累在浏览器历史记录中或磁盘上
  • 它们平常不存款和储蓄在服务器日志中
  • 它们不会传递到嵌入式能源,举个例子图片或 JavaScript
  • 它们仅适用于央求它们的域和路径

以下是我们的在线集团中,用于识别客户的 ASP.NET 会话 cookie 示例:

图片 5

请注意,cookie 被约束在域
store.httpwatch.com,何况在浏览器会话结束时过期(即不会蕴藏到磁盘)。

您本来能够经过 HTTPS
传递查询字符串,可是绝不在或者现身安全主题素材的情状下行使。举例,你能够少私寡欲的接收它们显示部分数字或许项目,像
accountview 或者
printpage,可是不要接受它们传递密码,银行卡号码或许别的不应该理解的新闻。

1 赞 收藏
评论

转载自

关于作者:xiaoheike

图片 6

简单介绍还未赶趟写 :)
个人主页 ·
小编的文章 ·
10 ·
     

图片 7

Get是向服务器发索取多少的生机勃勃种乞请,而Post是向服务器交由数据的生机勃勃种央求;

Get是获取信息,实际不是校订音信,相符数据库查询功能相通,数据不会被更换;

Get诉求的参数会跟在url后进行传递,央浼的多少会附在URL之后,以?分割UCR-VL和传输数据,参数之间以&相连,%XX中的XX为该符号以16进制表示的ASCII,若是数量是匈牙利(Magyarország)语字母/数字,原样发送,如若是空格,转变为+,要是是中文/其余字符,则一向把字符串用BASE64加密。

Get传输的数量有大大小小限定,因为GET是通过UXC90L提交数据,那么GET可交付的数据量就跟ULacrosseL的尺寸有一贯关联了,差别的浏览器对U奇骏L的长短的范围是差别的。

GET须要的数目会被浏览器缓存起来,顾客名和密码将公开出现在U大切诺基L上,其余人能够查到历史浏览记录,数据不太安全。在劳动器端,用Request.QueryString来收获Get格局交给来的数量;

Post要求则作为http新闻的实在内容发送给web服务器,数据放置在HTML
Header内提交,Post没有限制提交的数目。Post比Get安全,当数码是华语只怕不敏感的数码,则用get,因为运用get,参数博览会示在地点,对于敏感数据和不是华语字符的多寡,则用post;

string
name=Context.Request.QueryString[“name”]

POST表示恐怕改革变服务器上的能源的乞求,在劳动器端,用Post形式提交的多少只好用Request.Form来获取.

string
name=context.Request.Form[“pwd”];

admin

网站地图xml地图