WEB安全入門 1 （http篇）

本文爲網絡搬運整合，僅供學習使用，侵權聯繫刪除！

 

Web安全崗位需求

 

1 職位描述

對公司各種系統進行安全加固；

對公司網站、業務系統進行安全評估測試（黑盒、白盒測試）

對公司安全事件進行響應、清理後門、根據日誌分析攻擊途徑

安全技術研究，包括安全防範技術、黑客技術等；

跟蹤最新漏洞信息，進行業務產品的安全檢查。

2 崗位要求

熟悉Web滲透測試方法和攻防技術，包括SQL注入、XSS跨站、CSRF僞造請求、命令執行等OWSP TOP10 安全漏洞與防護；

熟悉Linux、Windows不一樣平臺的滲透測試，對網絡安全、系統安全、應用安全有深刻理解和本身的認識；

熟悉國內外安全工具，包括Kali、Linux、Metasploit、Nessus、Namp、AWVS、Burp等；

對Web安全總體有深入理解，有必定漏洞分析和挖掘能力；

本篇文章目錄參考連接：https://www.secpulse.com/archives/144410.html

一． HTTP基礎

1. HTTP協議介紹

(1) HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）,是因特網上應用最爲普遍的一種網絡傳輸協議，全部的WWW文件都必須遵照這個標準；

(2) HTTP是基於TCP/IP通訊協議來傳遞數據的（HTML 文件, 圖片文件, 查詢結果等）；

(3) HTTP協議一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了咱們常說的HTTPS；

(4) HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型,HTTP是一個無狀態的協議；

(5) HTTP默認的端口號爲80，HTTPS的端口號爲443；

 

1. HTTP工做流程

（1）用戶在瀏覽器輸入URL網址；

（2）瀏覽器根據URL網址中的域名，經過DNS解析出服務器IP地址；

（3）而後經過TCP/IP協議來和服務端創建連接（TCP三次握手）；

（4）創建連接後，發送請求給服務器；

（5）服務器回覆瀏覽器請求；

（6）瀏覽器拿到對應的html等資源，渲染頁面

3.  短連接

短鏈接的操做步驟是：

創建鏈接——數據傳輸——關閉鏈接，...創建鏈接——數據傳輸——關閉鏈接；

若是客戶請求頻繁，將在TCP的創建和關閉操做上浪費較多時間和帶寬；

4. 長連接

長連接,指在一個鏈接上能夠連續發送多個數據包，

在鏈接保持期間，若是沒有數據包發送，須要雙方發鏈路檢測包。

長連接操做步驟： 創建鏈接——數據傳輸...（保持鏈接）...數據傳輸——關閉鏈接。

長鏈接能夠省去較多的TCP創建和關閉的操做，減小浪費，節約時間。

5. HTTP存在的安全問題

可能被竊聽

(1) HTTP 自己不具有加密的功能,HTTP 報文使用明文方式發送;

(2) 因爲互聯網是由聯通世界各個地方的網絡設施組成,

全部發送和接收通過某些設備的數據均可能被截獲或窺視。(例如你們都熟悉的抓

包工具:Wireshark);

認證問題

（1）沒法確認你發送到的服務器就是真正的目標服務器(可能服務器是假裝的)；

（2）沒法肯定返回的客戶端是不是按照真實意圖接收的客戶端(多是假裝的客戶端)；

（3）可能被篡改

請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊被稱爲中間人攻擊。

二．HTTPS基礎

基於HTTP存在的一些安全問題，出現了HTTPS來解決這類問題

1. HTTPS介紹

超文本傳輸安全協議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，

常稱爲HTTP over TLS，HTTP over SSL或HTTP Secure）,是一種經過計算機網

絡進行安全通訊的傳輸協議。

HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密數據包。

HTTPS開發的主要目的，是提供對網站服務器的身份認證，保護交換數據的隱私

與完整性。簡言之，就是對HTTP加了一層安全策略

1. HTTPS怎麼解決HTTP存在的安全問題的？

HTTPS是在通訊接口部分用 TLS(Transport Layer Security 傳輸層安全性協議)；

TLS協議採用主從式架構模型，用於在兩個應用程序間經過網絡建立起安全的連

接，防止在交換數據時受到竊聽及篡改；

3. SSL和TLS的關係

 

(1) 傳輸層安全性協議（英語：Transport Layer Security，縮寫做 TLS），及其前

身安全套接層（Secure Sockets Layer，縮寫做 SSL）是一種安全協議，目的

是爲互聯網通訊，提供安全及數據完整性保障。

(2) 網景公司（Netscape）在1994年推出首版網頁瀏覽器，網景導航者時，推出

HTTPS協議，以SSL進行加密，這是SSL的起源。

(3) IETF將SSL進行標準化，1999年公佈初版TLS標準文件。隨後又公佈RFC

5246 （2008年8月）與 RFC 6176 （2011年3月）。

在瀏覽器、電子郵件、即時通訊、VoIP、網絡傳真等應用程序中，普遍支持這

個協議。

4 . TLS/SSL 協議

HTTPS 協議的主要功能基本都依賴於 TLS/SSL 協議。

TLS/SSL 的功能實現主要依賴於三類基本算法：散列函數 、對稱加密和非對稱

加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法採用協商的密

鑰對數據加密，基於散列函數驗證信息的完整性。

5.  HTTPS工做流程的通俗解釋

信鴿解釋，愛麗絲和鮑勃是經過信鴿異地聯繫

 開始階段

愛麗絲給鮑勃發了個飛鴿傳書。鮑勃收到了。很happy

但壞蛋馬洛裏攔截了愛麗絲的鴿子而且篡改了信息呢？

鮑勃就沒有辦法去知道愛麗絲髮出的信息在傳遞過程當中遭到了修改。

 

因而，愛麗絲和鮑勃見面商量後，決定對飛鴿傳書內容進行加密。

加密方式：他們會將信息中的每一個字母按照字母表中的順序前移三位。

好比，D→A，E→B，F→C。如此一來，原文爲 「secret」 的信息就變成了 「pbzobq」 。

這下。當愛麗絲給鮑勃再發了個飛鴿傳書時。

壞蛋馬洛裏攔截了信息也沒用；他不知道解密規則。

此時鮑勃收到信息消息後，再根據和愛麗絲商量的規則解密獲取信息。

他很得意本身的聰明才智。他們的作法就是對稱加密，但他們的作法存在一些問題。

他們須要見面才能肯定加密方式。這顯然不方便。

問題是若是愛麗絲和鮑勃在開始用信鴿傳信以前沒有見過面怎麼辦，

他們沒有一個安全的方式來確立密匙。若是他們本身來在信中傳遞密匙，

馬洛裏就會截獲信息並發現密匙。

這就使得馬洛裏能夠在愛麗絲和鮑勃開始加密他們的信息以前或以後，

閱讀到他們信息的內容並按照她的意願來篡改信息。

這是一箇中間人攻擊的典型例子，避免這個問題的惟一方法就是收發信的兩方一塊兒確

定加密方式。

 經過信鴿傳遞盒子

因此愛麗絲和鮑勃就想出了一個更好的系統。

當鮑勃想要給愛麗絲髮送信息時，他會按照以下的步驟來進行：

鮑勃向愛麗絲送一隻沒有攜帶任何信息的鴿子。

愛麗絲給鮑勃送回鴿子，而且這隻鴿子帶有一個有開着的鎖的盒子，愛麗絲保管着鎖

的鑰匙

鮑勃把信放進盒子中，把鎖鎖上而後把盒子送給愛麗絲。

愛麗絲收到盒子，用鑰匙打開而後閱讀信息。

這樣馬洛裏就不能經過截獲鴿子來篡改信息了，由於她沒有打開盒子的鑰匙。

當愛麗絲要給鮑勃發送消息的時候一樣按照上述的流程。

愛麗絲和鮑勃所使用的流程一般被稱爲非對稱密鑰加密。之因此稱之爲非對稱，是因

爲即便是你把信息編碼（鎖上盒子）也不能破譯信息（打開鎖住的盒子）

在術語中，盒子被稱爲公匙而用來打開盒子的鑰匙被稱爲私匙。

上面方式仍是會存在問題。

當鮑勃收到盒子時他如何能肯定這個盒子來自愛麗絲的，

而不是馬洛裏截獲了鴿子而後換了一個她有鑰匙能打開的盒子呢

如何信任盒子

愛麗絲決定簽名標記一下盒子，這樣鮑勃收到盒子的時候就能夠檢查簽名來肯定是愛

麗絲送出的盒子了。

那麼鮑勃如何打一開始就能識別出愛麗絲的簽名呢？這是個好問題。愛麗絲和鮑勃也

確實有這個問題，因此他們決定讓泰德代替愛麗絲來標記這個盒子。

那麼誰是泰德呢？泰德頗有名的，是一個值得信任的傢伙。他會給任何人簽名而且所

有人都信任他只會給合法的人簽名標記盒子。

若是泰德能夠確認索要簽名的人是愛麗絲，他就會在愛麗絲的盒子上簽名。所以馬洛

裏就不可能搞到一個有着泰德表明愛麗絲簽了名的盒子，由於鮑勃知道泰德只會給他

確認過的人簽名，從而識破馬洛裏的詭計。

泰德的角色在術語中被稱爲認證機構。而你閱讀此文時所用的瀏覽器打包存有許多認

證機構的簽名。

因此當你首次接入一個網站的時候你能夠信任來自這個站點的盒子由於你信任泰德

而泰德會告訴你盒子是合法的。

上述方式雖然比較完美的解決來存在的安全問題。

but，盒子裝東西太多過重。讓飛鴿傳書很慢。

這也是個問題

如何解決盒子過重問題

如今愛麗絲和鮑勃有了一個可靠的系統來進行交流，然他們也意識到讓鴿子攜帶盒子

比本來只攜帶信件要慢一些。

所以他們決定只有在選擇用對稱加密來給信息編碼（還記得凱撒加密法吧？）的密匙

時，使用傳遞盒子的方法（非對稱加密）。

這樣就能夠兩者的優勢兼具了，非對稱加密的可靠性和對稱加密的高效性。

現實世界中咱們不會用信鴿這樣慢的送信手段，但用非對稱加密來編碼信息仍要慢於

使用對稱加密技術，因此咱們只有在交換編碼密匙的時候會使用非對稱加密技術。

那麼相信如今的你已經大概瞭解了HTTPS是如何工做的了～～～

參考連接：https://juejin.cn/post/6844903842056765447

 

三．HTTP協議請求響應過程

 

1. HTTP請求

 

（1）HTTP協議的請求報文

 

當瀏覽器向服務器發送一個請求到Web服務器,它發送一個數據塊,或請求信息,

 

HTTP請求信息包括3部分:

 

請求方法URI協議/版本；

 

請求頭(Request Header)；

 

請求正文；

 

下面是一個HTTP請求的示例：

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

GET/test.jsp HTTP/1.1   Accept:image/test.image/jpeg,*/*   Accept-Language:zh-cn   Connection:Keep-Alive   Host:222.35.232.103   User-Agent:Mozila/5.0(compatible;MSIE5.01;Window NT5.0)   Accept-Encoding:gzip,deflate   username=bingyue&password=bingyue

 

　　

 

（1）請求方法URI協議/版本

 

請求的第一行是「方法/內容 URL協議/協議版本名稱」：

 

1	GET/test.jsp HTTP/1.1

 

上面的代碼中，「GET」說明請求方法，「/test.jsp」表示網絡資源，中間空格，最後說明

 

協議和協議的版本。

 

根據HTTP標準，HTTP請求可使用多種不一樣的請求方法。例如：HTTP1.1

 

容許支持七種請求方法（也叫「動做」）：GET、POST、HEAD、OPTIONS、PUT、

 

DELETE和TARCE。平常開發中， GET和POST是最經常使用的方法，主要在相關的

 

Web開發中。

 

URL路徑指定了要訪問的網絡資源。通常來講，咱們須要的是相對路徑，由於肯定資

 

源位置，知道網絡資源相對於服務器的根目錄的路徑就能夠，因此以「/」開頭。在頭信

 

息結束時，聲明瞭通訊過程當中HTTP協議版本的使用版本。

 

須要注意，方法名稱很重要的一點是嚴格區分大小寫。有些時候，某個請求所針對的

 

資源可能不支持對應的請求方法，會經過不一樣的狀態碼給出響應。例如,服務器將返

 

回一個狀態碼405(方法不容許),當請求服務器或方法不理解不支持相應的時間,返回

 

一個狀態碼501(沒有實現)。

 

（2）請求頭(Request Header)

 

請求頭包含了一些客戶環境和請求的內容信息。例如,請求頭能夠聲明瀏覽器內核和

 

語言使用,請求的長度等。

 

1 2 3 4 5 6 7 8 9 10 11

Accept:image/test.image/jpeg.*/*   Accept-Language:zh-cn   Connection:Keep-Alive   Host:222.35.232.103   User-Agent:Mozila/5.0(compatible:MSIE5.01:Windows NT5.0)   Accept-Encoding:gzip,deflate.

 

（3）請求正文

 

請求正文和請求頭要有空行。這個空行必須存在，說明結束請求頭傳輸，開始傳輸正

 

文請求。請求正文中通常包含不少信息，例如用戶提交的用戶名和密碼之類的登錄信

 

息：userlogin=bingyue¤tpwd=bingyue

 

在真實應用中，協議的請求正文能夠包含大量的信息,而不是如示例的HTTP請

 

求中同樣，請求正文只有簡單的一行數據。

 

2 . HTTP響應

 

和請求報文相似，HTTP響應主要也是3個部分構成：

 

（1）協議狀態版本代碼描述

 

（2）響應頭(Response Header)

 

（3）響應正文

 

下面是一個HTTP響應的示例：

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

HTTP/1.1 200 OK   Server:Apache Tomcat/7.0.1   Date:Mon,6Oct2014 13:23:42 GMT   Content-Length:102   <html> <head>   <title>HTTP響應文件<title>   </head>   <body>   這是HTTP響應文件！   </body>   </html>

 

客戶端向服務器發送請求，和請求報文相似，服務器會以狀態行響應。

 

響應報文包括：HTTP協議的版本、結果編碼以及其餘的必要信息，如實體信息等。

 

響應類別不一樣，響應報文裏能夠包含或者不含實體內容。

 

HTTP響應報文的首先是以狀態行開始，這些能夠參考示例的代碼。

 

響應頭也就是報文首部，和請求頭首部同樣，包含重要的信息，例子中咱們能夠看到，

 

好比日期時間和服務器類型以及內容長度和數量等。

 

參考連接：http://www.javashuo.com/article/p-fqcayhkg-cn.html

 

四．瞭解HTML、Javascript

 

1. HTML

 

   https://baike.baidu.com/item/HTML/97049?fr=aladdin

 

 

 

1. JAVACRIPT   

 

https://baike.baidu.com/item/JSP/141543?fr=aladdin

 

五． Get/Post區別

 

• GET 請求只能 URL 編碼，而 POST 支持多種編碼方式
• GET 請求只接受 ASCII 字符的參數，而 POST 則沒有限制
• GET 請求的參數經過 URL 傳送，而 POST 放在 Request Body 中
• GET 相對於 POST 更不安全，由於參數直接暴露在 URL 中
• GET 請求會被瀏覽器主動緩存，而 POST 不會（除非本身手動設置）
• GET 請求在 URL 傳參有長度限制，而 POST 則沒有限制
• GET 產生的 URL 地址能夠被收藏，而 POST 不能夠
• GET 請求的參數會被完整的保留在瀏覽器的歷史記錄裏，而 POST 的參數則不會
• GET 在瀏覽器回退時是無害的，而 POST 會再次提交請求

 

連接：https://www.zhihu.com/question/28586791/answer/774605294   

 

六． Cookie/Session是什麼？

 

1.背景介紹      

 

HTTP是一種無狀態的協議，爲了分辨連接是誰發起的，需本身去解決這個

 

問題。否則有些狀況下即便是同一個網站每打開一個頁面也都要登陸一下。

 

而Session和Cookie就是爲解決這個問題而提出來的兩個機制。

 

會話（Session）跟蹤是Web程序中經常使用的技術，用來跟蹤用戶的整個會話。

 

經常使用的會話跟蹤技術是Cookie與Session。Cookie經過在客戶端記錄信息確

 

定用戶身份，Session經過在服務器端記錄信息肯定用戶身份。

 

2 . cookie的主要內容

 

     主要包括：名字，值，過時時間，路徑和域。

 

     域：其中域能夠指定某一個域好比.google.com，也能夠指定一個域下的具體

 

某臺機器好比www.google.com或者froogle.google.com。能夠在java中經過

 

cookie.setDomain(".soncookie.com"); 設置，這個參數必須以「.」開始。

 

     路徑：就是跟在域名後面的URL路徑。

 

      路徑與域合在一塊兒就構成了cookie的做用範圍。

 

     過時時間：若是不設置過時時間，則表示這個cookie的生命期爲瀏覽器會

 

話期間，只要關閉瀏覽器窗口，cookie就消失了。這種cookie被稱爲會話

 

cookie。會話cookie是保存在內存裏，固然這種行爲並非規範規定的。如

 

果設置了過時時間，瀏覽器就會把cookie保存到硬盤上，關閉後再次打開

 

瀏覽器，這些cookie仍然有效直到超過設定的過時時間。

 

3 . session的主要內容

 

包括：名字，值，失效時間等。

 

      4 . Session和Cookie的主要區別

 

         (1) Cookie是把用戶的數據寫給用戶的瀏覽器;

 

        (2)Session技術把用戶的數據寫到用戶獨佔的session中;

 

        (3)Session對象由服務器建立，開發人員能夠調用request對象的

 

getSession方法獲得session對象。

 

     5 . Session和Cookie的應用場景

 

       (1)登陸網站，今輸入用戶名密碼登陸了，次日再打開不少狀況下就直接

 

打開了。這個時候用到的一個機制就是cookie。

 

       (2)session一個場景是購物車，添加了商品以後客戶端處能夠知道添加了哪

 

些商品，而服務器端如何判別呢，因此也須要存儲一些信息就用session。

 

 

 

詳細：http://www.javashuo.com/article/p-wkspuvrp-bz.html

 

七． Web安全專業術語

Webshell

 

菜刀

 

0day

 

SQL注入

 

上傳漏洞

 

XSS

 

CSRF

 

一句話木馬

 

其餘：http://www.javashuo.com/article/p-cccrgxnq-db.html

 

八． 滲透工具使用

 

1. Vmware安裝 下載地址：https://www.vmware.com/cn.html 

 

              密鑰：ZF3R0-FHED2-M80TY-8QYGC-NPKYF
                        YF390-0HF8P-M81RQ-2DXQE-M2UT6
                        ZF71R-DMX85-08DQY-8YMNC-PPHV8

 

         2. Windows/kali虛擬機安裝

         3. Phpstudy，DVWA環境搭建滲透測試靶場

         4. Java環境變量安裝

         5. Python環境變量安裝

         6. Sqlmap

         7. Burpsuite

         8. Nmap

         9. Nessus

        10. Appscan

        11. AWVS