你要離開家了, 所有的父母都會說,路上注意安全,可見安全是多麼的重要!那麼作為軟體開發,有哪些危險使我們要知道並避免的呢?
下面我說一些基本的需要知道的安全攻擊, 以及應對方案。
ps 作為乙個安全小白,了解各種各樣的防範方案真的太難了,我是真的水?。歡迎補充,以增長見識在使用者可以輸入的地方,並且將作為**編譯時,攻擊者可以通過輸入乙個指令碼位址的方式進行對頁面注入指令碼攻擊。解決方式: 任何使用者輸入的地方都不要相信,對使用者輸入內容進行轉義,如
<
使用轉義字串<
代替。
在使用者已登入的情況下,偽裝使用者的身份發起請求,進行相關攻擊。解決方式,確認使用者的身份。比較好理解的解決方式是: 二次確認,通過使用者的二次確認確認請求方為真實使用者。然後就是 x-requested-with 請求標誌,通過該請求頭設定標誌位ajax
請求,可以一定程度阻止跨域的偽裝。anti-csrf token
方案:通過服務端與客戶端唯一的 token 值進行校驗,可以看做乙個暗號,讓別人無法偽裝!
我們都知道jsonp
就是為了解決跨域的,如果傳輸資訊設計到比較敏感的資料,那麼別人可以很方便呼叫你的介面,獲取你的資料,儲存在自己的資料庫中。解決方法,新增指令碼可執行白名單,不要傳輸敏感資訊。
http 是明文傳輸,所以運營商可以知道你的**是什麼,然後在裡面加一點小廣告什麼的,改變你的內容。解決方法就是使用 https 協議,可恥的運營商
通過網域名稱解析我們才能找到對網域名稱的伺服器 ip 位址,劫持了 dns 就可以給你返回乙個錯誤的 ip 位址。在 dns 解析中,會先在本機搜尋網域名稱解析記錄,無相關記錄像 dns 服務商發起請求。所以要麼你本地資訊被篡改,要麼服務商欺騙你。
轉一篇 dns 劫持詳解鏈結
資料庫,插入資料庫的引數,在執行 sql 的時候小心它把你整個資料庫表給刪了。這裡的攻擊類似xss
攻擊,通過傳輸、拼接一些字串改變原本的 sql 語義
比如簡訊傳送訊息,非常的有代表性。通過介面的引數傳遞,以及最後的傳送內容,可以推測出你的推送內容的組合相關方式,就可以通過不良引數,很方便的傳送的一些不合法的資訊,或有毒鏈結給使用者。解決方式就是不要相信使用者傳入的任何引數,對引數進行校驗,傳送內容盡量可選擇匹配模式,如 code 值對映,對不合法的引數才有預設內容傳送。
就是很多請求大量湧入你的伺服器,導致它們都沒有空閒可以響應真正的使用者請求。通過 tcp 連線,我們知道建立連線需要三次確認,一般攻擊者可以偽造 ip, 發起大量連線請求,卻又不確認 = = 導致伺服器白白等待直到超時。其次可以借用別的使用者,在乙個大流量使用者**地方的某乙個頁面上了,通過xss
預設發起對攻擊**的請求,並傳送很大的資料,但每次傳送很少的位元組,這些使用者就被當成了肉雞,然後使其癱瘓。解決防範:增加機器, 對同乙個ip 的過多請求進行防範。
前端安全問題
核心 惡意指令碼注入 描述 攻擊者通過在目標 上注入惡意指令碼,使之在使用者的瀏覽器上執行。利用這些惡意指令碼,攻擊者可獲取使用者的敏感資訊如 cookie sessionid 等,進而危害資料安全。var htmlutil 2.用瀏覽器內部轉換器實現html解碼 htmldecode functi...
前端 安全 問題
看了一本書 web前端黑客技術揭秘 講了很多的前端安全性問題,這裡總結下常見的!不是挨個講解,只是講一下概念。1 sql注入攻擊 乙個例子說明一切 訪問 select from user table where id 1 訪問 union select from user table select ...
前端登入安全問題
對於前端開發來說安全問題很重要,我們不希望自己的密碼之類的資訊暴露出來被人獲取。如果前端不加以限制,很多重要資訊容易洩露。比如我們登入的時候,提交post,我們在瀏覽器控制台network的http請求中會直接看到密碼。http協議是明文傳輸,只要別人一抓包就可以獲取到傳輸的報文。那為了讓資料傳輸更...