網站安全

時間  2019-11-13
標籤 網站 安全 欄目 網站開發 简体版
原文   原文鏈接

webshellphp

 

發現這個也是巧合，我就直接說了吧html

<?php
//t.php
$test = $_GET['r'];
echo `$test`;
?>

你們看看這個代碼有木有問題？mysql

 我想你們都會說沒有問題，可是細心的朋友也會發現下面的變量被一個符號包起來了，既然是變量爲何要這樣了，web

信息安全團隊 並且又不是單引號，這個就是關鍵所在了，這個符號是 Esc 下面的一個鍵 感嘆號！旁邊的，算法

專一信息安全經過 echo `系統命令`; 能夠達到 system(); 同樣的效果sql

 

 

1、最基本的SQL注入shell

//防止SQl注入函數數據庫

//給提交到服務器端的數據用這個函數過濾一下
（1）編程

function data_filter($data){
    if (get_magic_quotes_gpc()) {  
        return $data = stripslashes($data); 
    }else{  
        return $data = mysql_real_escape_string($data); 
    } 
}後端

（2）

if (ini_get('magic_quotes_gpc')) {
function stripslashesRecursive(array $array){
foreach ($array as $k => $v) {
if (is_string($v)){
$array[$k] = stripslashes($v);
} else if (is_array($v)){
$array[$k] = stripslashesRecursive($v);
}
}
return $array;
}
$_GET = stripslashesRecursive($_GET);
$_POST = stripslashesRecursive($_POST);
}

 

2、本身平臺的一個表單提交入庫，別人是能夠知道你的這個地址，他本身在另外一個服務器寫一個表單腳本用for循環不斷提交表單給此地址，此地址若是沒作防禦，則會被這種行爲形成數據庫崩潰，因此說我們待想個辦法，以下：

/*
 * PHP防止站外提交數據的方法防止站外有人寫循環攻擊數據庫
 * 域名一致性判斷
 */
function CheckURL(){  
$servername=$_SERVER['SERVER_NAME'];    //當前服務器域名
$sub_from=$_SERVER["HTTP_REFERER"];     //上一個頁面的服務器域名
$sub_len=strlen($servername);                  
$checkfrom=substr($sub_from,7,$sub_len);   
if($checkfrom!=$servername)die("孩子，你是要經過這種方式搞個人數據庫？想一想其餘方法吧 f u c k！");  //校驗一致性便可
}  

3、經過瀏覽器，提交了表單，數據庫操做成功了，可是他經過瀏覽器的返回，返回上一頁，又一次提交數據，這樣會形成一條信息屢次填寫，如何避免，很簡單以下：

 window.history.forward(1); //加到js裏面，他就  回不去了，，，回不去了，，，咱們已成過去回不去了……
---------------------
做者：鍥而不捨
來源：CSDN
原文：https://blog.csdn.net/qq1355541448/article/details/42265375
版權聲明：本文爲博主原創文章，轉載請附上博文連接！

 

OWASP或Open Web Security Project是一家非營利性慈善組織，致力於提升軟件和Web應用程序的安全性。 
該組織根據來自各類安全組織的數據發佈頂級Web安全漏洞列表。 
根據可利用性，可檢測性和對軟件的影響，Web安全漏洞具備優先級。 
  • 可開發性 - 
    利用安全漏洞須要什麼？當攻擊僅須要Web瀏覽器且最低級別是高級編程和工具時，可攻擊性最高。
  • 可檢測性 - 
    檢測威脅有多容易？最高的是顯示在URL，表單或錯誤消息上的信息，最低的是源代碼。
  • 影響或損壞 - 
    若是安全漏洞暴露或受到攻擊，將會形成多大的破壞？最高的是完整的系統崩潰，最低的是什麼都沒有。
OWASP Top 10的主要目標是向開發人員，設計人員，經理，架構師和組織介紹最重要的安全漏洞。 
根據OWASP Top 10，十大安全漏洞是： 
  • SQL注入
  • 跨站腳本
  • 身份驗證和會話管理中斷
  • 不安全的直接對象引用
  • 跨站點請求僞造
  • 安全配置錯誤
  • 不安全的加密存儲
  • 沒法限制URL訪問
  • 傳輸層保護不足
  • 未經驗證的重定向和轉發
SQL注入 

 
描述 

注入是一個安全漏洞，容許攻擊者經過操縱用戶提供的數據來更改後端 SQL語句。 
當用戶輸入做爲命令或查詢的一部分被髮送到解釋器而且欺騙解釋器執行非預期的命令而且容許訪問未受權的數據時，發生注入。 
由Web應用程序執行時的SQL命令也能夠公開後端數據庫。 
意義 
  • 攻擊者能夠將惡意內容注入易受攻擊的字段。
  • 能夠從數據庫中讀取敏感數據，如用戶名，密碼等。
  • 能夠修改數據庫數據（插入/更新/刪除）。
  • 管理操做能夠在數據庫上執行
易受攻擊的對象 
  • 輸入字段
  • 與數據庫交互的URL。
例子： 
  • 登陸頁面上的SQL注入
在沒有有效憑據的狀況下登陸應用程序。 
有效的userName可用，密碼不可用。 
測試網址：http：//demo.testfire.net/default.aspx 
用戶名：sjones 
密碼：1 = 1'或pass123 
建立SQL查詢並將其發送到Interpreter，以下所示 
SELECT * FROM Users WHERE User_Name = sjones AND Password = 1 = 1'或pass123; 
建議 
  1. 白名單列出輸入字段
  2. 避免顯示對攻擊者有用的詳細錯誤消息。
跨站腳本 

描述 
Cross Site Scripting也簡稱爲XSS。 
XSS漏洞針對嵌入在客戶端（即用戶瀏覽器而不是服務器端）的頁面中嵌入的腳本。當應用程序獲取不受信任的數據並將其發送到Web瀏覽器而未經適當驗證時，可能會出現這些缺陷。 
在這種狀況下受害者瀏覽器，攻擊者可使用XSS對用戶執行惡意腳本。因爲瀏覽器沒法知道腳本是否可靠，腳本將被執行，攻擊者能夠劫持會話cookie，破壞網站或將用戶重定向到不須要的惡意網站。 
XSS是一種攻擊，容許攻擊者在受害者的瀏覽器上執行腳本。 

意義： 
  • 利用此安全漏洞，攻擊者能夠將腳本注入應用程序，能夠竊取會話cookie，破壞網站，並能夠在受害者的計算機上運行惡意軟件。
易受攻擊的對象 
  • 輸入字段
  • 網址
例子 
1. http://www.vulnerablesite.com/home?" < script > alert(" xss") </ script > 
上述腳本在瀏覽器上運行時，若是站點易受XSS攻擊，將顯示一個消息框。 
若是攻擊者想要顯示或存儲會話cookie，則能夠進行更嚴重的攻擊。 
2. http://demo.testfire.net/search.aspx?txtSearch <iframe > <src = http://google.com width = 500 height 500> </ iframe> 
上面的腳本運行時，瀏覽器會加載一個指向http://google.com的隱形框。 
經過在瀏覽器上運行惡意腳本可使攻擊變得嚴重。 
建議 
  1. 白名單輸入字段
  2. 輸入輸出編碼
身份驗證和會話管理中斷 

描述 
網站一般爲每一個有效會話建立會話cookie和會話ID，這些cookie包含敏感數據，如用戶名，密碼等。當會話經過註銷或瀏覽器忽然關閉結束時，這些cookie應該無效，即每一個會話應該有一個新的cookie。 
若是cookie未失效，則敏感數據將存在於系統中。例如，使用公共計算機（Cyber Cafe）的用戶，易受攻擊的站點的cookie位於系統上並暴露給攻擊者。攻擊者在一段時間後使用相同的公共計算機，敏感數據會受到損害。 
以一樣的方式，用戶使用公共計算機，而不是註銷，他忽然關閉瀏覽器。攻擊者使用相同的系統，當瀏覽同一個易受攻擊的站點時，受害者的上一個會話將被打開。攻擊者能夠經過竊取我的資料信息，信用卡信息等作任何他想作的事情。 
應該進行檢查以找到身份驗證和會話管理的強度。密鑰，會話令牌，cookie應該在不影響密碼的狀況下正確實施。 
易受攻擊的對象 
  • 在URL上公開的會話ID可能致使會話固定攻擊。
  • 註銷和登陸先後的會話ID相同。
  • 會話超時未正確實施。
  • 應用程序爲每一個新會話分配相同的會話ID。
  • 應用程序的通過身份驗證的部分使用SSL進行保護，密碼以散列或加密格式存儲。
  • 會話可由低權限用戶重用。
意義 
  • 利用此漏洞，攻擊者能夠劫持會話，對系統進行未經受權的訪問，從而容許泄露和修改未經受權的信息。
  • 使用盜取的cookie或使用XSS的會話能夠高舉會話。
例子 
  1. 航空公司預訂應用程序支持URL重寫，將會話ID放在URL中： 
    http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives（出售馬爾代夫門票） 

    該網站的通過身份驗證的用戶但願讓他的朋友瞭解該銷售併發送電子郵件。朋友收到會話ID，可用於進行未經受權的修改或濫用保存的信用卡詳細信息。
  2. 應用程序容易受到XSS攻擊，攻擊者能夠經過XSS訪問會話ID並可用於劫持會話。
  3. 應用程序超時未正確設置。用戶使用公共計算機並關閉瀏覽器，而不是註銷並離開。攻擊者稍後使用相同的瀏覽器，並對會話進行身份驗證。
建議 
  1. 應根據OWASP應用程序安全驗證標準定義全部身份驗證和會話管理要求。
  2. 永遠不要在URL或日誌中公開任何憑據。
  3. 還應該作出很大的努力來避免可用於竊取會話ID的XSS漏洞。

不安全的直接對象引用 

描述 
當開發人員公開對內部實現對象的引用（例如URL或FORM參數中的文件，目錄或數據庫鍵）時，就會發生這種狀況。攻擊者可使用此信息訪問其餘對象，並能夠建立未來的攻擊來訪問未經受權的數據。 
意義 
  • 使用此漏洞，攻擊者能夠訪問未經受權的內部對象，能夠修改數據或破壞應用程序。
易受攻擊的對象 
  • 在URL中。
例子： 
更改如下URL中的「userid」可使攻擊者查看其餘用戶的信息。 
http://www.vulnerablesite.com/userid=123修改成http://www.vulnerablesite.com/userid=124 
攻擊者能夠經過更改用戶標識值來查看其餘信息。 
建議： 
  1. 實施訪問控制檢查。
  2. 避免在URL中公開對象引用。
  3. 驗證對全部引用對象的受權。
跨站點請求僞造 

描述 
Cross Site Request Forgery是來自跨站點的僞造請求。 
CSRF攻擊是指惡意網站，電子郵件或程序致使用戶的瀏覽器在用戶當前已對其進行身份驗證的受信任站點上執行不須要的操做時發生的攻擊。 
CSRF攻擊強制登陸受害者的瀏覽器向易受攻擊的Web應用程序發送僞造的HTTP請求，包括受害者的會話cookie和任何其餘自動包含的身份驗證信息。 
當用戶在登陸原始網站時點擊URL時，攻擊者將向受害者發送連接，該數據將從網站上被竊取。 
意義 
  • 將此漏洞用做攻擊者能夠更改用戶配置文件信息，更改狀態，表明管理員建立新用戶等。
易受攻擊的對象 
  • 用戶檔案頁面
  • 用戶賬戶表單
  • 商業交易頁面
例子 
受害者使用有效憑據登陸銀行網站。他收到攻擊者的郵件說「請點擊此處捐贈1美圓。」 
當受害者點擊它時，將建立一個有效請求以向特定賬戶捐贈1美圓。 
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1 
攻擊者捕獲此請求並建立如下請求，並嵌入一個按鈕，說「我支持緣由」。 
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000 
因爲會話已經過身份驗證而且請求經過銀行網站發送，所以服務器將向攻擊者轉移1000美圓。 
建議 
  1. 在執行敏感操做時強制用戶在場。
  2. 實現CAPTCHA，從新認證和惟一請求令牌等機制。
安全配置錯誤 

描述 
必須爲應用程序，框架，應用程序服務器，Web服務器，數據庫服務器和平臺定義和部署安全性配置。若是這些配置正確，攻擊者可能會未經受權訪問敏感數據或功能。 
有時這種缺陷會致使系統徹底妥協。保持軟件最新也是很好的安全性。 
意義 
  • 利用此漏洞，攻擊者能夠枚舉底層技術和應用程序服務器版本信息，數據庫信息並獲取有關應用程序的信息以進行更多攻擊。
易受攻擊的對象 
  • 網址
  • 表格字段
  • 輸入字段
例子 
  1. 應用程序服務器管理控制檯將自動安裝，不會被刪除。默認賬戶不會更改。攻擊者可使用默認密碼登陸，並能夠得到未經受權的訪問。
  2. 您的服務器上未禁用目錄列表。攻擊者發現並能夠簡單地列出目錄以查找任何文件。
建議 
  1. 強大的應用程序架構，可在組件之間提供良好的分離和安全性。
  2. 更改默認用戶名和密碼。
  3. 禁用目錄列表並實施訪問控制檢查。
不安全的加密存儲 

描述 
不安全的加密存儲是一種常見的漏洞，在敏感數據未安全存儲時存在。 
用戶憑據，配置文件信息，健康詳細信息，信用卡信息等屬於網站上的敏感數據信息。 
該數據將存儲在應用程序數據庫中。若是不使用加密或散列*來不正確地存儲此數據，則它將容易受到攻擊者的攻擊。 
（* Hashing是將字符串字符轉換爲固定長度或密鑰的較短字符串。要解密字符串，用於造成密鑰的算法應該可用） 
意義 
  • 經過使用此漏洞，攻擊者能夠竊取，修改此類受弱保護的數據，以進行身份盜用，信用卡欺詐或其餘犯罪。
易受攻擊的對象 
  • 應用數據庫。
例子 
在其中一個銀行應用程序中，密碼數據庫使用未加保留的哈希*來存儲每一個人的密碼。SQL注入漏洞容許攻擊者檢索密碼文件。全部未加鹽的哈希均可以在任什麼時候候強行進行，而鹽漬的密碼則須要數千年的時間。 
（*無鹽哈希 - 鹽是附加到原始數據的隨機數據。在哈希以前將鹽附加到密碼） 
建議 
  1. 確保適當的強標準算法。不要建立本身的加密算法。僅使用通過批准的公共算法，如AES，RSA公鑰加密和SHA-256等。
  2. 確保異地備份已加密，但密鑰是單獨管理和備份的。
沒法限制URL訪問 

描述 
Web應用程序在呈現受保護的連接和按鈕以前檢查URL訪問權限 每次訪問這些頁面時，應用程序都須要執行相似的訪問控制檢查。 
在大多數應用程序中，特權頁面，位置和資源不會呈現給特權用戶。 
經過智能猜想，攻擊者能夠訪問權限頁面。攻擊者能夠訪問敏感頁面，調用函數和查看機密信息。 
意義 
  • 利用此漏洞攻擊者能夠訪問未經受權的URL，而無需登陸應用程序並利用此漏洞。攻擊者能夠訪問敏感頁面，調用函數和查看機密信息。
易受攻擊的對象： 
  • 網址
例子 
  1. 攻擊者注意到URL表示角色爲「/ user / getaccounts」。他修改成「/ admin / getaccounts」。
  2. 攻擊者能夠將角色附加到URL。
http://www.vulnerablsite.com能夠修改成http://www.vulnerablesite.com/admin 
建議 
  1. 實施強大的訪問控制檢查。
  2. 身份驗證和受權策略應基於角色。
  3. 限制對不須要的URL的訪問。
傳輸層保護不足 

描述 
處理用戶（客戶端）和服務器（應用程序）之間的信息交換。應用程序常常經過網絡傳輸敏感信息，如身份驗證詳細信息，信用卡信息和會話令牌。 
經過使用弱算法或使用過時或無效的證書或不使用SSL，能夠容許將通訊暴露給不受信任的用戶，這可能會危及Web應用程序和/或竊取敏感信息。 
意義 
  • 利用此Web安全漏洞，攻擊者能夠嗅探合法用戶的憑據並獲取對該應用程序的訪問權限。
  • 能夠竊取信用卡信息。
易受攻擊的對象 
  • 經過網絡發送的數據。
建議 
  1. 啓用安全HTTP並僅經過HTTPS強制執行憑據傳輸。
  2. 確保您的證書有效且未過時。
例子： 
1.不使用SSL的應用程序，攻擊者只會監視網絡流量並觀察通過身份驗證的受害者會話cookie。攻擊者能夠竊取該cookie並執行Man-in-the-Middle攻擊。 

未經驗證的重定向和轉發 

描述 
Web應用程序使用不多的方法將用戶重定向並轉發到其餘頁面以實現預期目的。 
若是在重定向到其餘頁面時沒有正確的驗證，攻擊者能夠利用此功能，並能夠將受害者重定向到網絡釣魚或惡意軟件站點，或者使用轉發來訪問未經受權的頁面。 
意義 
  • 攻擊者能夠向用戶發送包含附加編碼惡意URL的真實URL的URL。用戶只需看到攻擊者發送的URL的真實部分就能夠瀏覽它並可能成爲受害者。
例子 
1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com 
修改成 
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com 
建議 
  1. 只需避免在應用程序中使用重定向和轉發。若是使用，請不要在計算目的地時使用用戶參數。
  2. 若是沒法避免目標參數，請確保提供的值有效，併爲用戶受權。

轉載請註明本文連接： http://www.mayidui.net/t2095.html

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程