Web 架構(gòu)安全分析

Web 工作機制及基本概念

傳統(tǒng) Web 架構(gòu)

• LAMP

  

網(wǎng)頁

• 概念

  網(wǎng)頁就是我們可以通過瀏覽器上網(wǎng)看到的精美頁面，一般都是經(jīng)過瀏覽器渲染過的 .html 頁面，html 語言在瀏覽器中渲染。其中包含了CSS、JavaScript 等前端技術(shù)。通過瀏覽器訪問的 Web 頁面大部分都是 HTML 頁面。

• 靜態(tài)網(wǎng)頁

  靜態(tài)的網(wǎng)頁，都是一些 .html 文件，是純文本文件。這些文件中包含html 代碼。

  HTML（HyperText Markup Language，超文本標記語言），瀏覽器會通過渲染引擎解釋執(zhí)行 HTML 語言。

  HTML 語言對于 Web 容器來講就是純文本字符串。Web 容器只負責將 HTML 語言或其他字符串（字節(jié)流）從服務器傳輸給瀏覽器。靜態(tài)的頁面，只能將信息從 Web 容器傳遞到瀏覽器|客戶端|用戶。

網(wǎng)站

• 網(wǎng)站多個網(wǎng)頁的集合就是網(wǎng)站。

Web 服務器

• Web Server，也叫 Web 容器，主要提供 Web 服務，也就是常說的 httpd 服務。常見的 Web 容器有：Apache，IIS，Nginx 等。

中間件服務器（交互）

• 以上這種靜態(tài)網(wǎng)頁，只能單向地給用戶展示信息。隨著Web 的發(fā)展，信息要雙向流動，產(chǎn)生了交互的需求，也就是動態(tài)網(wǎng)頁的概念。

  所謂動態(tài)就是利用Flash、PHP、ASP、JAVA、JavaScript 等技術(shù)在網(wǎng)頁中嵌入一些可運行的腳本，用戶瀏覽器在解釋HTML 頁面時，遇到腳本就啟動運行它。腳本的使用讓Web 服務模式有了雙向交流的能力。

  Web 服務模式也可以像傳統(tǒng)軟件一樣進行各種事務處理，如編輯文件、利息計算、提交表單等，Web 架構(gòu)的適用面大大擴展。

  這些腳本可以嵌入在頁面中，如JS 等。也可以以文件的形式單獨存放在Web 服務器的目錄里，如.asp、.php、.jsp 文件等。我們在靜態(tài)網(wǎng)頁與腳本都是事前設計好的，一般不經(jīng)常改動，但網(wǎng)站上很多內(nèi)容需要經(jīng)常的更新，如新聞、博客文章、互動游戲等，這些變動的數(shù)據(jù)放在靜態(tài)的程序中顯然不適合，傳統(tǒng)的辦法是數(shù)據(jù)與程序分離，采用專業(yè)的數(shù)據(jù)庫。

  Web 開發(fā)者在Web 服務器后邊增加了一個數(shù)據(jù)庫服務器，這些經(jīng)常變化的數(shù)據(jù)存進數(shù)據(jù)庫，可以隨時更新。當用戶請求頁面時，腳本根據(jù)用戶請求的頁面，涉及到動態(tài)數(shù)據(jù)的地方，利用SQL 數(shù)據(jù)庫語言，從數(shù)據(jù)中讀取最新的數(shù)據(jù)，生成“完整”頁面，最后送給用戶。瀏覽器端看到的雖然是純文本HTML，它后端腳本的輸出（運行結(jié)果）。

  這樣功能性的腳本越來越多，形成常用的工具包，單獨管理，Web 業(yè)務開發(fā)時，直接使用就可以了，這就是中間件服務器，它實際上是Web 容器處理能力的擴展。

數(shù)據(jù)庫出現(xiàn)

• 靜態(tài)網(wǎng)頁與腳本都是事前設計好的，一般不經(jīng)常改動，但網(wǎng)站上很多內(nèi)容需要經(jīng)常的更新，如新聞、博客文章、互動游戲等，這些變動的數(shù)據(jù)放在靜態(tài)的程序中顯然不適合，傳統(tǒng)的辦法是數(shù)據(jù)與程序分離，采用專業(yè)的數(shù)據(jù)庫。

  Web 開發(fā)者在Web 服務器后邊增加了一個數(shù)據(jù)庫服務器，這些經(jīng)常變化的數(shù)據(jù)存進數(shù)據(jù)庫，可以隨時更新。當用戶請求頁面時，腳本根據(jù)用戶請求的頁面，涉及到動態(tài)數(shù)據(jù)的地方，利用SQL 數(shù)據(jù)庫語言，從數(shù)據(jù)中讀取最新的數(shù)據(jù)，生成“完整”頁面，最后送給用戶。

前后端分離架構(gòu)

前端

前端指的就是瀏覽器端展示的內(nèi)容。瀏覽器端有Web 頁面，功能邏輯，數(shù)據(jù)等內(nèi)容。

• Web 頁面，HTML + CSS + JS
• 功能邏輯，UI + JS
• 數(shù)據(jù)展示，AJAX

后端

后端為前端提供功能支持。后端開放API 接口。

• 頁面 API 接口
• 數(shù)據(jù) API 接口

HTTP 協(xié)議

HTTP 概述

• 超文本傳輸協(xié)議（Hyper Text Transfer Protocol，HTTP）是瀏覽器（Browser）與 Web 服務器（Web Server）之間的通信協(xié)議，是傳遞消息的規(guī)范和要求。

• HTTP 協(xié)議是1990 年提出的，當前最新版本3。HTTP 是用來將 HTML 文檔從 Web 服務器傳輸?shù)?Web 瀏覽器。

  即使訪問 PHP 文件，瀏覽器端接收到并不是 PHP 文件的源代碼，而是 PHP 腳本的運行結(jié)果，這個結(jié)果大部分是 HTML 文檔。

• HTTP 是一個請求和響應的協(xié)議。瀏覽器發(fā)出請求，服務器端對請求給出回應。

• HTTP 使用可靠的 TCP 連接，默認端口 80。

• HTTP 協(xié)議是以明文的方式在網(wǎng)絡中傳輸，容易被嗅探，這個風險也叫明文傳輸漏洞。

  為了解決明文傳輸?shù)膯栴}，需要使用加強版的HTTP 協(xié)議 - HTTPS，在HTTP 的基礎上加了一個安全套接字層 SSL（Security Socket Layer），使用默認端口443。

• HTTPS 也會有一些安全性問題，比如HTTPS 降級，“心臟滴血” 漏洞等。

HTTP 協(xié)議特點

• 支持瀏覽器/服務器模式（B/S）。

• 簡單快速：瀏覽器向服務器提出請求時，只需要傳送請求方法和請求路徑。

• 靈活：HTTP 允許傳輸任意類型的數(shù)據(jù)對象。

  文件后綴名	文件類型	MIME 類型
  .html	純文本	text/html
  .jpg	圖片	image/jpeg
  .mp3	音頻	audio/mpeg

• HTTP 協(xié)議是無狀態(tài)的協(xié)議。

URL

URL 概念

• 統(tǒng)一資源定位符（Uniform Resource Locator，URL），用來告訴Web 容器，瀏覽器所請求資源（文件）的路徑。例如：

  http://10.4.7.128/cms/show.php?id=32
  ftp://fptuser:ftpuser@10.9.69.254
  

URL 構(gòu)成

• 例

  schema://login:password@address:port/path/to/resource/?query_string#fragment
  

  URL 組成	說明	示例
  schema	協(xié)議	http
  ??/	–	–
  login	用戶名	–
  :	–	–
  password	密碼	–
  address	服務器地址（IP| 域名）	10.4.7.128
  :	–	–
  port	端口號	80
  /path/to/resource	請求資源路徑	/cms/show.php
  ?	–	–
  query_string	請求參數(shù)	id=32
  #	–	–
  fragment	錨點	–

  錨點就是在<a>標簽中實現(xiàn)頁面內(nèi)定位的，# 后面的內(nèi)容是不會傳遞服務器的。

URL 編碼

• 瀏覽器或服務器 URL 所允許出現(xiàn)的字符是有限制的。URL 中從 path 開始只允許出現(xiàn) A-Z，a-z，0-9，半角減號（-），下劃線（_），句點（.）,波浪號（~）。其他字符均會被 URL 編碼（編碼規(guī)則）。

  符號	URL 編碼
  #	%23
  \	%20
  &	%26
  >	%3e

  URL 編碼是一種編碼規(guī)則，它會將所有字符進行 URL 編碼。瀏覽器或服務器中對 URL 的要求，特殊字符進行 URL 編碼。URL 中的空格可用 %20，也可以用 + 來代替。

  http://10.9.65.213/cms/show.php?id=34 and 1=1
  http://10.9.65.213/cms/show.php?id=34%20and%201=1
  http://10.9.65.213/cms/show.php?id=34+and+1=1
  

• 可以在 burpsuite 的 Decoder 模塊中進行編碼

  

HTTP 請求（Request）報文格式

HTTP 請求由請求行、請求頭、請求正文三個部分組成。

請求行

• HTTP 報文的第一行，由空格字符分成三部分（空格、回車和換行符不能隨便出現(xiàn)）。

  列數(shù)	實例	說明
  第一列	GET	請求方法
  第二列	/cms/show.php?id=33	資源的路徑和GET 參數(shù)
  第三列	HTTP/1.1	協(xié)議/版本

• 常見請求方法如下：

  請求方法	說明
  GET	通常用于請求服務器發(fā)送某個資源
  POST	通常用于表單提交或文件上傳等功能
  HEAD	與GET 方法類似，但在服務器響應中只返回首部（頭部），沒有正文。
  OPTIONS	用來測試服務器所支持的方法
  TRACE	回顯瀏覽器的請求
  PUT	PUT 方法會向服務器寫入文檔
  DELETE	請求服務器刪除指定的資源

請求頭

• 從請求報文第二行開始到第一個空行為止之間的內(nèi)容。其中包含很多字段：

  主要字段	含義
  Host	主要用于指定被請求資源的服務器地址和端口號
  User-Agent	客戶端瀏覽器信息，瀏覽器指紋
  Referer	包含一個URL，代表當前URL 的上一個URL
  Cookie	記錄請求者的身份認證信息，身份證
  Content-Type	用于向接收方（瀏覽器或服務器）指示實體的介質(zhì)類型（數(shù)據(jù)類型，MIME）
  Content-Length	用于指明實體正文的長度，以字節(jié)方式存儲的十進制數(shù)字來表示
  Authorization	HTTP 基本認證

請求正文

• 帶有請求正文的，一般都是 POST 方法。第一個空行開始以后的所有內(nèi)容。

HTTP 常見傳參方式

• GET 傳參，向服務器提交的參數(shù)在 URL 中，http://ip/cms/show.php?id=33。?id=33 就是通過 GET 方式向服務器提交的參數(shù)。通過 GET 向服務器傳遞多個參數(shù)用 & 連接 ?name=AJEST&pass=123456，以此類推即可。

  GET 方法在**? 后連接參數(shù)**

• POST 傳參，向服務器提交的參數(shù)在請求正文中，如登錄功能 POST 數(shù)據(jù)包所示，向服務器提交了4個參數(shù)，& 連接

  username=admin&image.x=23&image.y=23&password=123456
  

  

HTTP 響應報文（Response）格式

狀態(tài)行

• 響應報文的第一行。

  列數(shù)	示例	解釋
  第一列	HTTP/1.1	協(xié)議/版本
  第二列	302	響應狀態(tài)碼
  第三列	Found	描述短語

• 常見狀態(tài)碼，如下：

  狀態(tài)代碼	類型	常見狀態(tài)碼
  1XX	信息性狀態(tài)碼	–
  2XX	成功狀態(tài)碼	200| 201…
  3XX	重定向狀態(tài)碼	302| 304…
  4XX	客戶端錯誤狀態(tài)碼	404| 403…
  5XX	服務器錯誤狀態(tài)碼	500

響應頭

• 響應報文第二行開始到第一個空行為止的所有內(nèi)容，其中包含了關于HTTP 響應的重要字段。

  字段	含義
  Date	時間和日期
  Server	Web 服務器指紋
  Last-Modified	服務器通過這個頭信息告訴瀏覽器，資源的最后修改時間
  Content-Length	響應正文的長度
  Content-Type	響應正文的類型
  Set-Cookie	服務器向瀏覽器端寫入Cookie 信息
  Location	重定向目標頁面
  Refresh	服務器通過Refresh 頭告訴瀏覽器定時刷新瀏覽器

響應正文

• 響應報文從第一個空行開始到最后的所有內(nèi)容。服務器返回資源的內(nèi)容，即瀏覽器接收到的 HTML 代碼。

Web 會話簡述

• 會話就是類似于瀏覽商品、加入購物車到支付，這樣一個完整的業(yè)務流程，要求有一個賬號始終保持登錄狀態(tài)，也就是說這個賬號完成了購買商品的業(yè)務。

• HTTP 協(xié)議本身是無狀態(tài)的協(xié)議，也就是說，HTTP 協(xié)議不會記錄會話狀態(tài)，不同的請求之間是沒有任何聯(lián)系的。很多種情況，瀏覽器與服務器之間的會話不是一個動作（請求）就完成了的。

• 希望在瀏覽器與服務器之間的這個交互的會話期間內(nèi)，服務器能夠保持對瀏覽器會話的識別，也就是保持HTTP 的狀態(tài)性。

Cookie 應運而生

• Cookie(Cookies) 就是指網(wǎng)站為了辨別用戶身份，進行會話跟蹤而存儲在用戶本地終端（瀏覽器）上一小段文本（數(shù)據(jù)，通常進行加密的）。

• Cookie 機制提供事務管理的功能，為服務器提供會話狀態(tài)管理。例如，購物車可以為每個用戶實現(xiàn)統(tǒng)計；實現(xiàn)授權(quán)策略等。

• Cookie 是服務器向瀏覽器寫入的一段文本（在響應報文的Set-Cookie 字段中），并存儲在瀏覽器中。另外，瀏覽器在訪問該網(wǎng)站時會自動發(fā)送 Cookie（在請求報文的Cookie 字段中），如果服務器識別這個自動發(fā)送的 Cookie 信息，也就是說，服務器識別了會話。

• 瀏覽器在訪問網(wǎng)站的時候，會自動攜帶與該網(wǎng)站相關聯(lián)的 Cookie 信息。

場景

• 去超市購物并注冊了會員，超市會發(fā)放一張會員卡。Cookie 就相當于這張會員卡，會員卡在會員手中，Cookie 在瀏覽器中。每次去超市買東西，一種情況是直接買，沒有優(yōu)惠；另外一種情況，出示會員卡，并享受打折優(yōu)惠，同時，通過購物可以獲取積分積累。超市會根據(jù)會員卡記錄，查詢積分消費情況，充值金額等等信息。

固定會話攻擊

竊取

• F12 調(diào)出控制臺輸入命令

  document.cookie;
  

• Cookie 信息：

  username=admin; userid=1; PHPSESSID=ne2q9bgvaml50b9uhvcr066fn7
  

• 也可以在 Application 中查看 cookie 信息

  

欺騙

• 在未登錄的情況下 cookie 中無信息

  

• 在控制臺設置 cookie 信息（先前登錄獲取的）

  document.cookie = "username=admin;";
  document.cookie = "userid=1;";
  document.cookie = "PHPSESSID=ne2q9bgvaml50b9uhvcr066fn7";
  

  

• url 中直接輸入管理員頁面的 url，無需輸入用戶名和密碼，按下回車

  

• 直接登錄成功

  文章來源地址http://www.zghlxwxcb.cn/news/detail-753510.html

到了這里，關于Web架構(gòu)安全分析/http/URL/Cookie攻擊的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！