❶ Web應用 密碼復雜度設置
Web應用密碼復雜度設置至少包含兩種字元的組合，至少一個小寫字母。
默認設置了密碼安全策略，但用戶可取消，建議用戶啟用該策略：密碼長度為8到128個字元。
❷ web.py怎樣安全地傳遞密碼
保護密碼最好的的方式就是使用帶鹽的密碼hash(salted password hashing).對密碼進行hash操作是一件很簡單的事情，但是很多人都犯了錯。接下來我希望可以詳細的闡述如何恰當的對密碼進行hash，以及為什麼要這樣做。
重要提醒
如果你打算自己寫一段代碼來進行密碼hash，那麼趕緊停下吧。這樣太容易犯錯了。這個提醒適用於每一個人，不要自己寫密碼的hash演算法 ！關於保存密碼的問題已經有了成熟的方案，那就是使用phpass或者本文提供的源碼。
什麼是hash
hash("hello") =
hash("hbllo") =
hash("waltz") =
Hash演算法是一種單向的函數。它可以把任意數量的數據轉換成固定長度的「指紋」，這個過程是不可逆的。而且只要輸入發生改變，哪怕只有一個bit，輸出的hash值也會有很大不同。這種特性恰好合適用來用來保存密碼。因為我們希望使用一種不可逆的演算法來加密保存的密碼，同時又需要在用戶登陸的時候驗證密碼是否正確。
在一個使用hash的賬號系統中，用戶注冊和認證的大致流程如下：
1, 用戶創建自己的賬號
2, 用戶密碼經過hash操作之後存儲在資料庫中。沒有任何明文的密碼存儲在伺服器的硬碟上。
3, 用戶登陸的時候，將用戶輸入的密碼進行hash操作後與資料庫里保存的密碼hash值進行對比。
4, 如果hash值完全一樣，則認為用戶輸入的密碼是正確的。否則就認為用戶輸入了無效的密碼。
5, 每次用戶嘗試登陸的時候就重復步驟3和步驟4。
在步驟4的時候不要告訴用戶是賬號還是密碼錯了。只需要顯示一個通用的提示，比如賬號或密碼不正確就可以了。這樣可以防止攻擊者枚舉有效的用戶名。
還需要注意的是用來保護密碼的hash函數跟數據結構課上見過的hash函數不完全一樣。比如實現hash表的hash函數設計的目的是快速，但是不夠安全。只有加密hash函數(cryptographic hash functions)可以用來進行密碼的hash。這樣的函數有SHA256, SHA512, RipeMD, WHIRLPOOL等。
一個常見的觀念就是密碼經過hash之後存儲就安全了。這顯然是不正確的。有很多方式可以快速的從hash恢復明文的密碼。還記得那些md5破解網站吧，只需要提交一個hash，不到一秒鍾就能知道結果。顯然，單純的對密碼進行hash還是遠遠達不到我們的安全需求。下一部分先討論一下破解密碼hash，獲取明文常見的手段。
如何破解hash
字典和暴力破解攻擊(Dictionary and Brute Force Attacks)
最常見的破解hash手段就是猜測密碼。然後對每一個可能的密碼進行hash，對比需要破解的hash和猜測的密碼hash值，如果兩個值一樣，那麼之前猜測的密碼就是正確的密碼明文。猜測密碼攻擊常用的方式就是字典攻擊和暴力攻擊。
Dictionary Attack
Trying apple : failed
Trying blueberry : failed
Trying justinbeiber : failed
...
Trying letmein : failed
Trying s3cr3t : success!
字典攻擊是將常用的密碼，單詞，短語和其他可能用來做密碼的字元串放到一個文件中，然後對文件中的每一個詞進行hash，將這些hash與需要破解的密碼hash比較。這種方式的成功率取決於密碼字典的大小以及字典的是否合適。
Brute Force Attack
Trying aaaa : failed
Trying aaab : failed
Trying aaac : failed
...
Trying acdb : failed
Trying acdc : success!
暴力攻擊就是對於給定的密碼長度，嘗試每一種可能的字元組合。這種方式需要花費大量的計算機時間。但是理論上只要時間足夠，最後密碼一定能夠破解出來。只是如果密碼太長，破解花費的時間就會大到無法承受。
目前沒有方式可以阻止字典攻擊和暴力攻擊。只能想辦法讓它們變的低效。如果你的密碼hash系統設計的是安全的，那麼破解hash唯一的方式就是進行字典或者暴力攻擊了。
查表破解(Lookup Tables)
對於特定的hash類型，如果需要破解大量hash的話，查表是一種非常有效而且快速的方式。它的理念就是預先計算(pre-compute)出密碼字典中每一個密碼的hash。然後把hash和對應的密碼保存在一個表裡。一個設計良好的查詢表結構，即使存儲了數十億個hash，每秒鍾仍然可以查詢成百上千個hash。
如果你想感受下查表破解hash的話可以嘗試一下在CraskStation上破解下下面的sha256 hash。
反向查表破解(Reverse Lookup Tables)
Searching for hash(apple) in users' hash list... : Matches [alice3, 0bob0, charles8]
Searching for hash(blueberry) in users' hash list... : Matches [usr10101, timmy, john91]
Searching for hash(letmein) in users' hash list... : Matches [wilson10, dragonslayerX, joe1984]
Searching for hash(s3cr3t) in users' hash list... : Matches [bruce19, knuth1337, john87]
Searching for hash(z@29hjja) in users' hash list... : No users used this password
這種方式可以讓攻擊者不預先計算一個查詢表的情況下同時對大量hash進行字典和暴力破解攻擊。
首先，攻擊者會根據獲取到的資料庫數據製作一個用戶名和對應的hash表。然後將常見的字典密碼進行hash之後，跟這個表的hash進行對比，就可以知道用哪些用戶使用了這個密碼。這種攻擊方式很有效果，因為通常情況下很多用戶都會有使用相同的密碼。
彩虹表 (Rainbow Tables)
彩虹表是一種使用空間換取時間的技術。跟查表破解很相似。只是它犧牲了一些破解時間來達到更小的存儲空間的目的。因為彩虹表使用的存儲空間更小，所以單位空間就可以存儲更多的hash。彩虹表已經能夠破解8位長度的任意md5hash。彩虹表具體的原理可以參考http://www.project-rainbowcrack.com/
下一章節我們會討論一種叫做「鹽」(salting)的技術。通過這種技術可以讓查表和彩虹表的方式無法破解hash。
加鹽(Adding Salt)
hash("hello") =
hash("hello" + "QxLUF1bgIAdeQX") =
hash("hello" + "bv5PehSMfV11Cd") =
hash("hello" + "YYLmfY6IehjZMQ") =
查表和彩虹表的方式之所以有效是因為每一個密碼的都是通過同樣的方式來進行hash的。如果兩個用戶使用了同樣的密碼，那麼一定他們的密碼hash也一定相同。我們可以通過讓每一個hash隨機化，同一個密碼hash兩次，得到的不同的hash來避免這種攻擊。
具體的操作就是給密碼加一個隨即的前綴或者後綴，然後再進行hash。這個隨即的後綴或者前綴成為「鹽」。正如上面給出的例子一樣，通過加鹽，相同的密碼每次hash都是完全不一樣的字元串了。檢查用戶輸入的密碼是否正確的時候，我們也還需要這個鹽，所以鹽一般都是跟hash一起保存在資料庫里，或者作為hash字元串的一部分。
鹽不需要保密，只要鹽是隨機的話，查表，彩虹表都會失效。因為攻擊者無法事先知道鹽是什麼，也就沒有辦法預先計算出查詢表和彩虹表。如果每個用戶都是使用了不同的鹽，那麼反向查表攻擊也沒法成功。
下一節，我們會介紹一些鹽的常見的錯誤實現。
錯誤的方式：短的鹽和鹽的復用
最常見的錯誤實現就是一個鹽在多個hash中使用或者使用的鹽很短。
鹽的復用(Salt Reuse)
不管是將鹽硬編碼在程序里還是隨機一次生成的，在每一個密碼hash里使用相同的鹽會使這種防禦方法失效。因為相同的密碼hash兩次得到的結果還是相同的。攻擊者就可以使用反向查表的方式進行字典和暴力攻擊。只要在對字典中每一個密碼進行hash之前加上這個固定的鹽就可以了。如果是流行的程序的使用了硬編碼的鹽，那麼也可能出現針對這種程序的這個鹽的查詢表和彩虹表，從而實現快速破解hash。
用戶每次創建或者修改密碼一定要使用一個新的隨機的鹽
短的鹽
如果鹽的位數太短的話，攻擊者也可以預先製作針對所有可能的鹽的查詢表。比如，3位ASCII字元的鹽，一共有95x95x95 = 857,375種可能性。看起來好像很多。假如每一個鹽製作一個1MB的包含常見密碼的查詢表，857,375個鹽才是837GB。現在買個1TB的硬碟都只要幾百塊而已。
基於同樣的理由，千萬不要用用戶名做為鹽。雖然對於每一個用戶來說用戶名可能是不同的，但是用戶名是可預測的，並不是完全隨機的。攻擊者完全可以用常見的用戶名作為鹽來製作查詢表和彩虹表破解hash。
根據一些經驗得出來的規則就是鹽的大小要跟hash函數的輸出一致。比如，SHA256的輸出是256bits(32bytes),鹽的長度也應該是32個位元組的隨機數據。
錯誤的方式：雙重hash和古怪的hash函數
這一節討論另外一個常見的hash密碼的誤解:古怪的hash演算法組合。人們可能解決的將不同的hash函數組合在一起用可以讓數據更安全。但實際上，這種方式帶來的效果很微小。反而可能帶來一些互通性的問題，甚至有時候會讓hash更加的不安全。本文一開始就提到過，永遠不要嘗試自己寫hash演算法，要使用專家們設計的標准演算法。有些人會覺得通過使用多個hash函數可以降低計算hash的速度，從而增加破解的難度。通過減慢hash計算速度來防禦攻擊有更好的方法，這個下文會詳細介紹。
下面是一些網上找到的古怪的hash函數組合的樣例。
md5(sha1(password))
md5(md5(salt) + md5(password))
sha1(sha1(password))
sha1(str_rot13(password + salt))
md5(sha1(md5(md5(password) + sha1(password)) + md5(password)))
不要使用他們！
注意：這部分的內容其實是存在爭議的！我收到過大量郵件說組合hash函數是有意義的。因為如果攻擊者不知道我們用了哪個函數，就不可能事先計算出彩虹表，並且組合hash函數需要更多的計算時間。
攻擊者如果不知道hash演算法的話自然是無法破解hash的。但是考慮到Kerckhoffs』s principle,攻擊者通常都是能夠接觸到源碼的(尤其是免費軟體和開源軟體)。通過一些目標系統的密碼–hash對應關系來逆向出演算法也不是非常困難。
如果你想使用一個標準的」古怪」的hash函數，比如HMAC，是可以的。但是如果你的目的是想減慢hash的計算速度，那麼可以讀一下後面討論的慢速hash函數部分。基於上面討論的因素，最好的做法是使用標準的經過嚴格測試的hash演算法。
hash碰撞(Hash Collisions)
因為hash函數是將任意數量的數據映射成一個固定長度的字元串，所以一定存在不同的輸入經過hash之後變成相同的字元串的情況。加密hash函數(Cryptographic hash function)在設計的時候希望使這種碰撞攻擊實現起來成本難以置信的高。但時不時的就有密碼學家發現快速實現hash碰撞的方法。最近的一個例子就是MD5，它的碰撞攻擊已經實現了。
碰撞攻擊是找到另外一個跟原密碼不一樣，但是具有相同hash的字元串。但是，即使在相對弱的hash演算法，比如MD5,要實現碰撞攻擊也需要大量的算力(computing power),所以在實際使用中偶然出現hash碰撞的情況幾乎不太可能。一個使用加鹽MD5的密碼hash在實際使用中跟使用其他演算法比如SHA256一樣安全。不過如果可以的話，使用更安全的hash函數，比如SHA256, SHA512, RipeMD, WHIRLPOOL等是更好的選擇。
正確的方式：如何恰當的進行hash
這部分會詳細討論如何恰當的進行密碼hash。第一個章節是最基礎的，這章節的內容是必須的。後面一個章節是闡述如何繼續增強安全性，讓hash破解變得異常困難。
基礎：使用加鹽hash
我們已經知道惡意黑客可以通過查表和彩虹表的方式快速的獲得hash對應的明文密碼，我們也知道了通過使用隨機的鹽可以解決這個問題。但是我們怎麼生成鹽，怎麼在hash的過程中使用鹽呢？
鹽要使用密碼學上可靠安全的偽隨機數生成器(Cryptographically Secure Pseudo-Random Number Generator (CSPRNG))來產生。CSPRNG跟普通的偽隨機數生成器比如C語言中的rand(),有很大不同。正如它的名字說明的那樣，CSPRNG提供一個高標準的隨機數，是完全無法預測的。我們不希望我們的鹽能夠被預測到，所以一定要使用CSPRNG。
❸ 如何實現一個安全的Web登陸
對於 Web 應用程序，安全登錄是很重要的。但是目前大多數 Web 系統在發送登錄密碼時是發送的明文，這樣很容易被入侵者監聽到密碼。當然，通過 SSL
來實現安全連接是個不錯的方法，但是很多情況下我們沒辦法將伺服器設置為帶有 SSL 的 Web 伺服器。因此如果在登錄系統中加入安全登錄機制，則可以在沒有 SSL
的 Web 伺服器上實現安全登錄。
要實現安全登錄，可以採用下面三種方法，一種基於非對稱加密演算法，一種基於對稱加密演算法，最後一種基於散列演算法。
非對稱加密演算法中，目前最常用的是 RSA 演算法和
ECC(橢圓曲線加密)演算法。要採用非對稱加密演算法實現安全登錄的話，首先需要在客戶端向伺服器端請求登錄頁面時，伺服器生成公鑰和私鑰，然後將公鑰隨登錄頁面一起傳遞給客戶端瀏覽器，當用戶輸入完用戶名密碼點擊登錄時，登錄頁面中的
JavaScript
調用非對稱加密演算法對用戶名和密碼用用公鑰進行加密。然後再提交到伺服器端，伺服器端利用私鑰進行解密，再跟資料庫中的用戶名密碼進行比較，如果一致，則登錄成功，否則登錄失敗。
對稱加密演算法比非對稱加密演算法要快得多，但是對稱加密演算法需要數據發送方和接受方共用一個密鑰，密鑰是不能通過不安全的網路直接傳遞的，否則密鑰和加密以後的數據如果同時監聽到的話，入侵者就可以直接利用監聽到的密鑰來對加密後的信息進行解密了。
如何用 hmac
演算法實現安全登錄。首先在客戶端向伺服器端請求登錄頁面時，伺服器端生成一個隨機字元串，連同登錄頁面一同發送給客戶端瀏覽器，當用戶輸入完用戶名密碼後，將密碼採用
MD5 或者 SHA1 來生成散列值作為密鑰，伺服器端發送來的隨機字元串作為消息數據，進行 hmac
運算。然後將結果提交給伺服器。之所以要對用戶輸入的密碼進行散列後再作為密鑰，而不是直接作為密鑰，是為了保證密鑰足夠長，而又不會太長。伺服器端接受到客戶端提交的數據後，將保存在伺服器端的隨機字元串和用戶密碼進行相同的運算，然後進行比較，如果結果一致，則認為登錄成功，否則登錄失敗。當然如果不用
hmac 演算法，直接將密碼和伺服器端生成的隨機數合並以後再做 MD5 或者 SHA1，應該也是可以的。
這里客戶端每次請求時伺服器端發送的隨機字元串都是不同的，因此即使入侵者監聽到了這個隨機字元串和加密後的提交的數據，它也無法再次提交相同的數據通過驗證。而且通過監聽到的數據也無法計算出密鑰，所以也就無法偽造登錄信息了。
對稱和非對稱加密演算法不僅適用於登錄驗證，還適合用於最初的密碼設置和以後密碼修改的過程中，而散列演算法僅適用於登錄驗證。但是散列演算法要比對稱和非對稱加密演算法效率高。
❹ 用Web上Q安全嗎密碼會不會被偷
官方答復——
安全機制是這次作為首要因素考慮的，為vhttp協議傳輸，所以協議加密都重新加密做了，消息加密，本地加密，密碼安全都做了保障。
建議用360安全瀏覽器~~
❺ Web應用常見的安全漏洞有哪些
Web應用常見的安全漏洞：
1、SQL注入
注入是一個安全漏洞，允許攻擊者通過操縱用戶提供的數據來更改後端SQL語句。當用戶輸入作為命令或查詢的一部分被發送到解釋器並且欺騙解釋器執行非預期的命令並且允許訪問未授權的數據時，發生注入。
2、跨站腳本攻擊 （XSS）
XSS漏洞針對嵌入在客戶端（即用戶瀏覽器而不是伺服器端）的頁面中嵌入的腳本。當應用程序獲取不受信任的數據並將其發送到Web瀏覽器而未經適當驗證時，可能會出現這些缺陷。
3、跨站點請求偽造
CSRF攻擊是指惡意網站，電子郵件或程序導致用戶的瀏覽器在用戶當前已對其進行身份驗證的受信任站點上執行不需要的操作時發生的攻擊。
4、無法限制URL訪問
Web應用程序在呈現受保護的鏈接和按鈕之前檢查URL訪問許可權 每次訪問這些頁面時，應用程序都需要執行類似的訪問控制檢查。通過智能猜測，攻擊者可以訪問許可權頁面。攻擊者可以訪問敏感頁面，調用函數和查看機密信息。
5、不安全的加密存儲
不安全的加密存儲是一種常見的漏洞，在敏感數據未安全存儲時存在。用戶憑據，配置文件信息，健康詳細信息，信用卡信息等屬於網站上的敏感數據信息。
(5)Web密碼安全擴展閱讀
web應用漏洞發生的市場背景：
由於Web伺服器提供了幾種不同的方式將請求轉發給應用伺服器，並將修改過的或新的網頁發回給最終用戶，這使得非法闖入網路變得更加容易。
許多程序員不知道如何開發安全的應用程序。他們的經驗也許是開發獨立應用程序或Intranet Web應用程序，這些應用程序沒有考慮到在安全缺陷被利用時可能會出現災難性後果。
許多Web應用程序容易受到通過伺服器、應用程序和內部已開發的代碼進行的攻擊。這些攻擊行動直接通過了周邊防火牆安全措施，因為埠80或443（SSL，安全套接字協議層）必須開放，以便讓應用程序正常運行。
❻ 如何保證Web伺服器安全
不但企業的門戶網站被篡改、資料被竊取，而且還成為了病毒與木馬的傳播者。有些Web管理員採取了一些措施，雖然可以保證門戶網站的主頁不被篡改，但是卻很難避免自己的網站被當作肉雞，來傳播病毒、惡意插件、木馬等等。筆者認為，這很大一部分原因是管理員在Web安全防護上太被動。他們只是被動的防禦。為了徹底提高Web伺服器的安全，筆者認為，Web安全要主動出擊。具體的來說，需要做到如下幾點。一、在代碼編寫時就要進行漏洞測試 現在的企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的，是通過代碼堆積起來的。如果這個代碼只供企業內部使用，那麼不會帶來多大的安全隱患。但是如果放在互聯網上使用的話，則這些為實現特定功能的代碼就有可能成為攻擊者的目標。筆者舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊，來獲取管理員的密碼等等破壞性的動作。有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時，其實就有可能在安裝一個木馬(這可能訪問者與被訪問者都沒有意識到)。 為此在為網站某個特定功能編寫代碼時，就要主動出擊。從編碼的設計到編寫、到測試，都需要認識到是否存在著安全的漏洞。筆者在日常過程中，在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。至少現在已知的病毒、木馬不能夠在你所開發的插件中有機可乘。通過這層層把關，就可以提高代碼編寫的安全性。二、對Web伺服器進行持續的監控 冰凍三尺、非一日之寒。這就好像人生病一樣，都有一個過程。病毒、木馬等等在攻擊Web伺服器時，也需要一個過程。或者說，在攻擊取得成功之前，他們會有一些試探性的動作。如對於一個採取了一定安全措施的Web伺服器，從攻擊開始到取得成果，至少要有半天的時間。如果Web管理員對伺服器進行了全天候的監控。在發現有異常行為時，及早的採取措施，將病毒與木馬阻擋在門戶之外。這種主動出擊的方式，就可以大大的提高Web伺服器的安全性。 筆者現在維護的Web伺服器有好幾十個。現在專門有一個小組，來全天候的監控伺服器的訪問。平均每分鍾都可以監測到一些試探性的攻擊行為。其中99%以上的攻擊行為，由於伺服器已經採取了對應的安全措施，都無功而返。不過每天仍然會遇到一些攻擊行為。這些攻擊行為可能是針對新的漏洞，或者採取了新的攻擊方式。在伺服器上原先沒有採取對應的安全措施。如果沒有及時的發現這種行為，那麼他們就很有可能最終實現他們的非法目的。相反，現在及早的發現了他們的攻擊手段，那麼我們就可以在他們採取進一步行動之前，就在伺服器上關掉這扇門，補上這個漏洞。 筆者在這里也建議，企業用戶在選擇互聯網Web伺服器提供商的時候，除了考慮性能等因素之外，還要評估服務提供商能否提供全天候的監控機制。在Web安全上主動出擊，及時發現攻擊者的攻擊行為。在他們採取進一步攻擊措施之前，就他們消除在萌芽狀態。 三、設置蜜罐，將攻擊者引向錯誤的方向 在軍隊中，有時候會給軍人一些偽裝，讓敵人分不清真偽。其實在跟病毒、木馬打交道時，本身就是一場無硝煙的戰爭。為此對於Web伺服器採取一些偽裝，也能夠將攻擊者引向錯誤的方向。等到供給者發現自己的目標錯誤時，管理員已經鎖定了攻擊者，從而可以及早的採取相應的措施。筆者有時候將這種主動出擊的行為叫做蜜罐效應。簡單的說，就是設置兩個伺服器。其中一個是真正的伺服器，另外一個是蜜罐。現在需要做的是，如何將真正的伺服器偽裝起來，而將蜜罐推向公眾。讓攻擊者認為蜜罐伺服器才是真正的伺服器。要做到這一點的話，可能需要從如下幾個方面出發。 一是有真有假，難以區分。如果要瞞過攻擊者的眼睛，那麼蜜罐伺服器就不能夠做的太假。筆者在做蜜罐伺服器的時候，80%以上的內容都是跟真的伺服器相同的。只有一些比較機密的信息沒有防治在蜜罐伺服器上。而且蜜罐伺服器所採取的安全措施跟真的伺服器事完全相同的。這不但可以提高蜜罐伺服器的真實性，而且也可以用來評估真實伺服器的安全性。一舉兩得。 二是需要有意無意的將攻擊者引向蜜罐伺服器。攻擊者在判斷一個Web伺服器是否值得攻擊時，會進行評估。如評估這個網站的流量是否比較高。如果網站的流量不高，那麼即使被攻破了，也沒有多大的實用價值。攻擊者如果沒有有利可圖的話，不會花這么大的精力在這個網站伺服器上面。如果要將攻擊者引向這個蜜罐伺服器的話，那麼就需要提高這個蜜罐伺服器的訪問量。其實要做到這一點也非常的容易。現在有很多用來交互流量的團隊。只要花一點比較小的投資就可以做到這一點。 三是可以故意開一些後門讓攻擊者來鑽。作為Web伺服器的管理者，不僅關心自己的伺服器是否安全，還要知道自己的伺服器有沒有被人家盯上。或者說，有沒有被攻擊的價值。此時管理者就需要知道，自己的伺服器一天被攻擊了多少次。如果攻擊的頻率比較高，管理者就高興、又憂慮。高興的是自己的伺服器價值還蠻大的，被這么多人惦記著。憂慮的是自己的伺服器成為了眾人攻擊的目標。就應該抽取更多的力量來關注伺服器的安全。四、專人對Web伺服器的安全性進行測試 俗話說，靠人不如靠自己。在Web伺服器的攻防戰上，這一個原則也適用。筆者建議，如果企業對於Web服務的安全比較高，如網站伺服器上有電子商務交易平台，此時最好設置一個專業的團隊。他們充當攻擊者的角色，對伺服器進行安全性的測試。這個專業團隊主要執行如下幾個任務。 一是測試Web管理團隊對攻擊行為的反應速度。如可以採用一些現在比較流行的攻擊手段，對自己的Web伺服器發動攻擊。當然這個時間是隨機的。預先Web管理團隊並不知道。現在要評估的是，Web管理團隊在多少時間之內能夠發現這種攻擊的行為。這也是考驗管理團隊全天候跟蹤的能力。一般來說，這個時間越短越好。應該將這個時間控制在可控的范圍之內。即使攻擊最後沒有成功，Web管理團隊也應該及早的發現攻擊的行為。畢竟有沒有發現、與最終有沒有取得成功，是兩個不同的概念。 二是要測試伺服器的漏洞是否有補上。畢竟大部分的攻擊行為，都是針對伺服器現有的漏洞所產生的。現在這個專業團隊要做的就是，這些已發現的漏洞是否都已經打上了安全補丁或者採取了對應的安全措施。有時候我們都沒有發現的漏洞是無能為力，但是對於這些已經存在的漏洞不能夠放過。否則的話，也太便宜那些攻擊者了。
❼ 如何進行WEB安全性測試
安全性測試
產品滿足需求提及的安全能力
n 應用程序級別的安全性，包括對數據或業務功能的訪問，應
用程序級別的安全性可確保：在預期的安全性情況下，主角
只能訪問特定的功能或用例，或者只能訪問有限的數據。例
如，可能會允許所有人輸入數據，創建新賬戶，但只有管理
員才能刪除這些數據或賬戶。如果具有數據級別的安全性，
測試就可確保「用戶類型一」 能夠看到所有客戶消息（包括
財務數據），而「用戶二」只能看見同一客戶的統計數據。
n 系統級別的安全性，包括對系統的登錄或遠程訪問。
系統級別的安全性可確保只有具備系統訪問許可權的用戶才能
訪問應用程序，而且只能通過相應的網關來訪問。
安全性測試應用
防SQL漏洞掃描
– Appscan
n防XSS、防釣魚
– RatProxy、Taint、Netsparker
nget、post -> 防止關鍵信息顯式提交
– get：顯式提交
– post：隱式提交
ncookie、session
– Cookie欺騙
❽ 如何進行WEB安全性測試
一般來說，一個WEB應用包括WEB伺服器運行的操作系統、WEB伺服器、WEB應用邏輯、資料庫幾個部分，其中任何一個部分出現安全漏洞，都會導致整個系統的安全性問題。
對操作系統來說，最關鍵的操作系統的漏洞，Windows上的RPC漏洞、緩沖區溢出漏洞、安全機制漏洞等等；
對WEB伺服器來說，WEB伺服器從早期僅提供對靜態HTML和圖片進行訪問發展到現在對動態請求的支持，早已是非常龐大的系統。
對應用邏輯來說，根據其實現的語言不同、機制不同、由於編碼、框架本身的漏洞或是業務設計時的不完善，都可能導致安全上的問題。
對WEB的安全性測試是一個很大的題目，首先取決於要達到怎樣的安全程度。不要期望網站可以達到100%的安全，須知，即使是美國國防部，也不能保證自己的網站100%安全。對於一般的用於實現業務的網站，達到這樣的期望是比較合理的：
1、能夠對密碼試探工具進行防範；
2、能夠防範對cookie攻擊等常用攻擊手段；
3、敏感數據保證不用明文傳輸；
4、能防範通過文件名猜測和查看HTML文件內容獲取重要信息；
5、能保證在網站收到工具後在給定時間內恢復，重要數據丟失不超過1個小時；
❾ Web前端密碼加密是否有意義
在前端對密碼做一次MD5，看起來是防止明文傳輸了，事實上只有一種情況下它可以提高用戶的安全性，那就是用戶在別的網站上也用和你的網站一樣的密碼。並且在任何情況下都提高不了你自己網站的安全性。前面說的傳輸過程、內存里、日誌里……這些地方沒有明文密碼，其實都只能保護用戶本身的利益，對於自身服務的安全性是沒有提高的。因為，既然傳輸過程不是加密的，那麼包隨便發，至於發一個abc123，還是發一個，對你的程序沒有任何的區別，這時候你的程序都是小綿羊。這個過程可以看做，你的用戶都用了32位字元串的密碼，如是而已。從事實意義上講，在所有網站上用同樣密碼的用戶非常多，所以可以勉勉強強的說，這是有一丁丁點的意義的。但即使在前端做了簽名，因為hash暴露了，也還是很容易被撞庫。但是，對安全性沒有提高，就不做了嗎？當然要做，因為要應付審計。
❿ Web前端密碼加密是否有意義
密碼在前端加密完全沒有意義，對密碼系統的安全性不會有任何提高，反而會引發不必要的麻煩。首先，做前端開發的人需要知道，前端系統的控制權是完全在用戶手裡的，也就是說，前端做什麼事情，用戶有完全的控制權。假設如同 @陳軒所說，前端做過了md5，後台就不用做了，這個做法會有什麼後果？如果某一天，這個系統的資料庫泄露了，黑客就直接拿到了每個用戶的密碼md5值，但此時，由於黑客知道密碼是在前端進行哈希的，所以他不需要爆破出該md5對應的原文是什麼，而是直接修改客戶端向伺服器發出的請求，把密碼欄位換成資料庫中MD5就可以了，由於與資料庫中記錄一致，直接就會登錄成功。這跟直接存儲明文密碼沒有任何區別！！！所以不管前端是不是加密了密碼，後台使用安全的哈希演算法對內容再次轉換是非常有必要的。（MD5可不行，要用bcrypt，我之前回答過一個類似的：隨著顯卡性能的高速發展，目前的快速Hash演算法是否已經變得不夠安全了？）這個回答還有一個人贊同，希望大家別被錯誤答案誤導了。另外一個答案 @林鴻所說，在非安全HTTP連接上，可以防止原始密碼被竊聽。但問題在於由於你的登錄系統接受的哈希過的密碼，而不是原文，竊聽者根本不需要原始密碼，只要通過哈希結果就可以偽造請求登錄系統。這樣做只能防止被竊聽到原文的密碼被攻擊者用在社會學攻擊上，而不能改善該網站的安全性。所以不管前端是不是加密了密碼，使用HTTPS安全連接進行登錄都是非常有必要的。以上我說的兩點，合起來看就是：不管前端是否加密了密碼，都不能以此為假設，讓後端設計的安全等級下降，否則就會有嚴重的安全問題。實際上，前端進行密碼加密，可以看做幫助用戶多進行了一次原文的轉換，不管用了什麼加密演算法，算出來的結果都是密碼原文，你該如何保護用戶的原始密碼，就該如何保護此處的加密結果，因為對你的登錄系統來說，它們都是密碼原文。以上這些，說明了密碼加密是沒有什麼意義的，接下來，我要說明前端加密會帶來什麼問題。有些人會認為前端進行了加密，可以降低後台的安全性需求，這種錯誤的觀念會造成系統的安全漏洞。實際上，你不能對前端做任何的假設，所有跟安全相關的技術，都必須應用在後台上。前端進行加密會造成頁面需要js腳本才能運行，那麼假設你的系統需要兼容不能運行js的客戶端，就必須再設計一個使用原文的登錄介面。由於前端是不是加密，所有安全機制都必須照常應用，所以為系統增加這樣的復雜性是完全沒必要的，即使傳輸明文密碼，只要正確使用了HTTPS連接和伺服器端安全的哈希演算法，密碼系統都可以是很安全的。