偽隨機數噪馏，是通過一些數學算法生成的隨機數祟滴，并非真正的隨機數振惰。密碼學上的安全偽隨機數應該是不可壓縮的。對應的“真隨機數”踱启，則是通過一些物理系統生成的隨機數报账，比如電壓的波動、硬盤磁頭讀/寫時的尋道時間埠偿、空中電磁波的噪聲等透罢。
在Web應用中，使用偽隨機數的地方非常廣泛冠蒋。密碼羽圃、key、SessionID抖剿、token等許多非常關鍵的“secret”往往都是通過偽隨機數算法生成的朽寞。
很多偽隨機數算法與系統時間有關，而有的程序員甚至就直接使用系統時間代替隨機數的生成斩郎。這樣生成的隨機數脑融，是根據時間順序增長的，可以從時間上進行預測缩宜，從而存在安全隱患肘迎。
偽隨機數是由數學算法實現的，它真正隨機的地方在于“種子（seed）”锻煌。種子一旦確定后妓布，再通過同一偽隨機數算法計算出來的隨機數，其值是固定的宋梧，多次計算所得值的順序也是固定的匣沼。
建立在這個基礎上，就可以得到一種可行的攻擊方式：
（1）通過一些方法猜解出種子的值捂龄；
（2）通過mt_srand()對猜解出的種子值進行播種释涛；
（3）通過還原程序邏輯，計算出對應的mt_rand()產生的偽隨機數的值跺讯。
在一個Web應用中枢贿，有很多地方都可以獲取到隨機數，從而提供猜解種子的可能刀脏。Stefan Esser提供了一種“CrossApplication Attacks”的思路局荚，即通過前一個應用在頁面上返回的隨機數值，猜解出其他應用生成的隨機數值。
Stefan Esser描述這個攻擊過程如下：
（1）使用Keep-Alive HTTP請求在phpBB2論壇中搜索字符串‘a’耀态；
（2）搜索必然會出來很多結果轮傍，同時也泄露了search_id；
（3）很容易通過該值猜解出隨機數的種子首装；
（4）攻擊者仍然使用Keep-AliveHTTP頭發(fā)送一個重置admin密碼的請求給WordPressblog创夜；
（5）WordPress mt_rand()生成確認鏈接，并發(fā)送到管理員郵箱仙逻；
（6）攻擊者根據已算出的種子驰吓，可以構造出此確認鏈接；
（7）攻擊者確認此鏈接（仍然使用Keep-Alive頭）系奉，WordPress將向管理員郵箱發(fā)送新生成的密碼檬贰；
（8）因為新密碼也是由mt_rand()生成的，攻擊者仍然可以計算出來缺亮；
（9）從而攻擊者最終獲取了新的管理員密碼翁涤。
在重要或敏感的系統中，一定要使用足夠強壯的隨機數生成算法萌踱。在Java中葵礼，可以使用java.security.SecureRandom；而在Linux中并鸵，可以使用/dev/random或者/dev/urandom來生成隨機數鸳粉，只需要讀取即可；而在PHP 5.3.0及其之后的版本中园担，若是支持openSSL擴展赁严，也可以直接使用函數來生成隨機數。
除了以上方法外粉铐，從算法上還可以通過多個隨機數的組合，以增加隨機數的復雜性卤档。比如通過給隨機數使用MD5算法后蝙泼，再連接一個隨機字符，然后再使用MD5算法一次劝枣。這些方法汤踏，也將極大地增加攻擊的難度。
MVC框架安全
在現代Web開發(fā)中舔腾，使用MVC架構是一種流行的做法溪胶。MVC是Model-View-Controller的縮寫，它將Web應用分為三層稳诚，View層負責用戶視圖哗脖、頁面展示等工作；Controller負責應用的邏輯實現，接收View層傳入的用戶請求才避，并轉發(fā)給對應的Model做處理橱夭；Model層則負責實現模型，完成數據的處理桑逝。
從數據的流入來看棘劣，用戶提交的數據先后流經了View層、Controller楞遏、Model層茬暇，數據的流出則反過來。在設計安全方案時寡喝，要牢牢把握住數據這個關鍵因素糙俗。在MVC框架中，通過切片拘荡、過濾器等方式臼节，往往能對數據進行全局處理，這為設計安全方案提供了極大的便利珊皿。
一些主要的Web安全威脅网缝，如XSS、CSRF蟋定、SQL注入粉臊、訪問控制、認證驶兜、URL跳轉等不涉及業(yè)務邏輯的安全問題扼仲，都可以集中放在MVC框架中解決。
在框架中實施安全方案抄淑，比由程序員在業(yè)務中修復一個個具體的bug屠凶，有著更多的優(yōu)勢。
首先肆资，有些安全問題可以在框架中統一解決矗愧，能夠大大節(jié)省程序員的工作量，節(jié)約人力成本郑原。當代碼的規(guī)模大到一定程度時唉韭，在業(yè)務的壓力下，專門花時間去一個個修補漏洞幾乎成為不可能完成的任務犯犁。
其次属愤，對于一些常見的漏洞來說，由程序員一個個修補可能會出現遺漏酸役，而在框架中統一解決住诸，有可能解決“遺漏”的問題驾胆。這需要制定相關的代碼規(guī)范和工具配合。
最后只壳，在每個業(yè)務里修補安全漏洞俏拱，補丁的標準難以統一，而在框架中集中實施的安全方案吼句，可以使所有基于框架開發(fā)的業(yè)務都能受益锅必，從安全方案的有效性來說，更容易把握惕艳。
Struts2命令執(zhí)行漏洞
springMVC命令執(zhí)行漏洞
Django命令執(zhí)行漏洞
常見的DDOS攻擊有SYN flood搞隐、UDP flood、ICMP flood等远搪。其中SYNflood是一種最為經典的DDOS攻擊劣纲，其發(fā)現于1996年，但至今仍然保持著非常強大的生命力谁鳍。SYN flood如此猖獗是因為它利用了TCP協議設計中的缺陷癞季，而TCP/IP協議是整個互聯網的基礎，牽一發(fā)而動全身倘潜，如今想要修復這樣的缺陷幾乎成為不可能的事情绷柒。
在正常情況下，TCP三次握手過程如下：
（1）客戶端向服務器端發(fā)送一個SYN包涮因，包含客戶端使用的端口號和初始序列號x废睦；
（2）服務器端收到客戶端發(fā)送來的SYN包后，向客戶端發(fā)送一個SYN和ACK都置位的TCP報文养泡，包含確認號xx1和服務器端的初始序列號y嗜湃；
（3）客戶端收到服務器端返回的SYNSACK報文后，向服務器端返回一個確認號為yy1澜掩、序號為xx1的ACK報文购披，一個標準的TCP連接完成。
而SYN flood在攻擊時肩榕，首先偽造大量的源IP地址今瀑，分別向服務器端發(fā)送大量的SYN包，此時服務器端會返回SYN/ACK包点把，因為源地址是偽造的，所以偽造的IP并不會應答屿附，服務器端沒有收到偽造IP的回應郎逃，會重試3～5次并且等待一個SYNTime（一般為30秒至2分鐘），如果超時則丟棄這個連接挺份。攻擊者大量發(fā)送這種偽造源地址的SYN請求褒翰，服務器端將會消耗非常多的資源（CPU和內存）來處理這種半連接，同時還要不斷地對這些IP進行SYN+ACK重試。最后的結果是服務器無暇理睬正常的連接請求优训，導致拒絕服務朵你。
對抗SYN flood的主要措施有SYNCookie/SYN Proxy、safereset等算法揣非。SYN Cookie的主要思想是為每一個IP地址分配一個“Cookie”抡医，并統計每個IP地址的訪問頻率。如果在短時間內收到大量的來自同一個IP地址的數據包早敬，則認為受到攻擊忌傻，之后來自這個IP地址的包將被丟棄。
應用層DDOS搞监，不同于網絡層DDOS水孩，由于發(fā)生在應用層，因此TCP三次握手已經完成琐驴，連接已經建立俘种，所以發(fā)起攻擊的IP地址也都是真實的。但應用層DDOS有時甚至比網絡層DDOS攻擊更為可怕绝淡，因為今天幾乎所有的商業(yè)Anti-DDOS設備宙刘，只在對抗網絡層DDOS時效果較好，而對應用層DDOS攻擊卻缺乏有效的對抗手段够委。
CC攻擊的原理：對一些消耗資源較大的應用頁面不斷發(fā)起正常的請求荐类，以達到消耗服務端資源的目的。在Web應用中茁帽，查詢數據庫玉罐、讀/寫硬盤文件等操作，相對都會消耗比較多的資源潘拨。
應用層DDOS攻擊還可以通過以下方式完成：在黑客入侵了一個流量很大的網站后吊输，通過篡改頁面，將巨大的用戶流量分流到目標網站铁追。
應用層DDOS攻擊是針對服務器性能的一種攻擊季蚂，那么許多優(yōu)化服務器性能的方法，都或多或少地能緩解此種攻擊琅束。比如將使用頻率高的數據放在memcache中扭屁，相對于查詢數據庫所消耗的資源來說，查詢memcache所消耗的資源可以忽略不計涩禀。但很多性能優(yōu)化的方案并非是為了對抗應用層DDOS攻擊而設計的料滥，因此攻擊者想要找到一個資源消耗大的頁面并不困難。比如當memcache查詢沒有命中時艾船，服務器必然會查詢數據庫葵腹，從而增大服務器資源的消耗高每，攻擊者只需要找到這樣的頁面即可。同時攻擊者除了觸發(fā)“讀”數據操作外践宴，還可以觸發(fā)“寫”數據操作鲸匿，“寫”數據的行為一般都會導致服務器操作數據庫。
最常見的針對應用層DDOS攻擊的防御措施阻肩，是在應用中針對每個“客戶端”做一個請求頻率的限制带欢。
通過IP地址與Cookie 定位一個客戶端，如果客戶端的請求在一定時間內過于頻繁磺浙，則對之后來自該客戶端的所有請求都重定向到一個出錯頁面洪囤。
從架構上看，這段代碼需要放在業(yè)務邏輯之前撕氧，才能起到保護后端應用的目的瘤缩，可以看做是一個“基層”的安全模塊。
然而這種防御方法并不完美伦泥，因為它在客戶端的判斷依據上并不是永遠可靠的剥啤。這個方案中有兩個因素用以定位一個客戶端：一個是IP地址，另一個是Cookie不脯。但用戶的IP地址可能會發(fā)生改變府怯，而Cookie又可能會被清空，如果IP地址和Cookie同時都發(fā)生了變化防楷，那么就無法再定位到同一個客戶端了牺丙。
如何讓IP地址發(fā)生變化呢？使用“代理服務器”是一個常見的做法复局。在實際的攻擊中冲簿，大量使用代理服務器或傀儡機來隱藏攻擊者的真實IP地址，已經成為一種成熟的攻擊模式亿昏。攻擊者使用這些方法可不斷地變換IP地址峦剔，就可以繞過服務器對單個IP地址請求頻率的限制了。
防御首先角钩，應用代碼要做好性能優(yōu)化吝沫。合理地使用memcache，將數據庫的壓力盡可能轉移到內存中递礼。此外還需要及時地釋放資源惨险，比如及時關閉數據庫連接，減少空連接等消耗脊髓。
其次平道，在網絡架構上做好優(yōu)化。善于利用負載均衡分流供炼，避免用戶流量集中在單臺服務器上一屋。同時可以充分利用好CDN和鏡像站點的分流作用，緩解主站的壓力袋哼。
最后冀墨，也是最重要的一點，實現一些對抗手段涛贯，比如限制每個IP地址的請求頻率诽嘉。
