2. 程式人生 > >【轉】常見六大Web 安全攻防解析

【轉】常見六大Web 安全攻防解析

阿新 • • 發佈：2019-02-01
nor 介紹 ech 應用 shel 想要 後端 key 正則表達

原文轉自：https://segmentfault.com/a/1190000018073845

作者：浪裏行舟

在互聯網時代，數據安全與個人隱私受到了前所未有的挑戰，各種新奇的攻擊技術層出不窮。如何才能更好地保護我們的數據？本文主要側重於分析幾種常見的攻擊的類型以及防禦的方法。

一、XSS

XSS (Cross-Site Scripting)，跨站腳本攻擊，因為縮寫和 CSS重疊，所以只能叫 XSS。跨站腳本攻擊是指通過存在安全漏洞的Web網站註冊用戶的瀏覽器內運行非法的HTML標簽或JavaScript進行的一種攻擊。

跨站腳本攻擊有可能造成以下影響:

  • 利用虛假輸入表單騙取用戶個人信息。
  • 利用腳本竊取用戶的Cookie值，被害者在不知情的情況下，幫助攻擊者發送惡意請求。
  • 顯示偽造的文章或圖片。

XSS 的原理是惡意攻擊者往 Web 頁面裏插入惡意可執行網頁腳本代碼，當用戶瀏覽該頁之時，嵌入其中 Web 裏面的腳本代碼會被執行，從而可以達到攻擊者盜取用戶信息或其他侵犯用戶安全隱私的目的。

XSS 的攻擊方式千變萬化，但還是可以大致細分為幾種類型。

1.非持久型 XSS（反射型 XSS ）

非持久型 XSS 漏洞，一般是通過給別人發送帶有惡意腳本代碼參數的 URL，當 URL 地址被打開時，特有的惡意代碼參數被 HTML 解析、執行。

技術分享圖片
舉一個例子，比如頁面中包含有以下代碼：

<select>
    <script>
        document.write(‘‘
            + ‘<option value=1>‘
            +     location.href.substring(location.href.indexOf(‘default=‘) + 8)
            + ‘</option>‘
        );
        document.write(‘<option value=2>English</option>‘);
    </script>
</select>

攻擊者可以直接通過 URL (類似：https://xxx.com/xxx?default=<script>alert(document.cookie)</script>) 註入可執行的腳本代碼。不過一些瀏覽器如Chrome其內置了一些XSS過濾器，可以防止大部分反射型XSS攻擊。

非持久型 XSS 漏洞攻擊有以下幾點特征：

  • 即時性，不經過服務器存儲，直接通過 HTTP 的 GET 和 POST 請求就能完成一次攻擊，拿到用戶隱私數據。
  • 攻擊者需要誘騙點擊,必須要通過用戶點擊鏈接才能發起
  • 反饋率低，所以較難發現和響應修復
  • 盜取用戶敏感保密信息

為了防止出現非持久型 XSS 漏洞，需要確保這麽幾件事情：

  • Web 頁面渲染的所有內容或者渲染的數據都必須來自於服務端。
  • 盡量不要從 URL，document.referrer，document.forms 等這種 DOM API 中獲取數據直接渲染。
  • 盡量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可執行字符串的方法。
  • 如果做不到以上幾點，也必須對涉及 DOM 渲染的方法傳入的字符串參數做 escape 轉義。
  • 前端渲染的時候對任何的字段都需要做 escape 轉義編碼。

2.持久型 XSS（存儲型 XSS）

持久型 XSS 漏洞，一般存在於 Form 表單提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入數據庫持久保存，當前端頁面獲得後端從數據庫中讀出的註入代碼時，恰好將其渲染執行。

技術分享圖片

舉個例子，對於評論功能來說，就得防範持久型 XSS 攻擊，因為我可以在評論中輸入以下內容

技術分享圖片

主要註入頁面方式和非持久型 XSS 漏洞類似，只不過持久型的不是來源於 URL，referer，forms 等，而是來源於後端從數據庫中讀出來的數據 。持久型 XSS 攻擊不需要誘騙點擊，黑客只需要在提交表單的地方完成註入即可，但是這種 XSS 攻擊的成本相對還是很高。

攻擊成功需要同時滿足以下幾個條件：

  • POST 請求提交表單後端沒做轉義直接入庫。
  • 後端從數據庫中取出數據沒做轉義直接輸出給前端。
  • 前端拿到後端數據沒做轉義直接渲染成 DOM。

持久型 XSS 有以下幾個特點：

  • 持久性，植入在數據庫中
  • 盜取用戶敏感私密信息
  • 危害面廣

3.如何防禦

對於 XSS 攻擊來說，通常有兩種方式可以用來防禦。

1) CSP

CSP 本質上就是建立白名單，開發者明確告訴瀏覽器哪些外部資源可以加載和執行。我們只需要配置規則，如何攔截是由瀏覽器自己實現的。我們可以通過這種方式來盡量減少 XSS 攻擊。

通常可以通過兩種方式來開啟 CSP：

  • 設置 HTTP Header 中的 Content-Security-Policy
  • 設置 meta 標簽的方式 <meta http-equiv="Content-Security-Policy">

這裏以設置 HTTP Header 來舉例：

  • 只允許加載本站資源
Content-Security-Policy: default-src ‘self‘
  • 只允許加載 HTTPS 協議圖片
Content-Security-Policy: img-src https://*
  • 允許加載任何來源框架
Content-Security-Policy: child-src ‘none‘

如需了解更多屬性，請查看Content-Security-Policy文檔

對於這種方式來說，只要開發者配置了正確的規則，那麽即使網站存在漏洞，攻擊者也不能執行它的攻擊代碼，並且 CSP 的兼容性也不錯。

2) 轉義字符

用戶的輸入永遠不可信任的，最普遍的做法就是轉義輸入輸出的內容，對於引號、尖括號、斜杠進行轉義

function escape(str) {
  str = str.replace(/&/g, ‘&amp;‘)
  str = str.replace(/</g, ‘&lt;‘)
  str = str.replace(/>/g, ‘&gt;‘)
  str = str.replace(/"/g, ‘&quto;‘)
  str = str.replace(/‘/g, ‘&#39;‘)
  str = str.replace(/`/g, ‘&#96;‘)
  str = str.replace(/\//g, ‘&#x2F;‘)
  return str
}

但是對於顯示富文本來說，顯然不能通過上面的辦法來轉義所有字符，因為這樣會把需要的格式也過濾掉。對於這種情況，通常采用白名單過濾的辦法，當然也可以通過黑名單過濾，但是考慮到需要過濾的標簽和標簽屬性實在太多，更加推薦使用白名單的方式。

const xss = require(‘xss‘)
let html = xss(‘<h1 id="title">XSS Demo</h1><script>alert("xss");</script>‘)
// -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;
console.log(html)

以上示例使用了 js-xss 來實現，可以看到在輸出中保留了 h1 標簽且過濾了 script 標簽。

3) HttpOnly Cookie。

這是預防XSS攻擊竊取用戶cookie最有效的防禦手段。Web應用程序在設置cookie時，將其屬性設為HttpOnly，就可以避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。

二、CSRF

CSRF(Cross Site Request Forgery)，即跨站請求偽造，是一種常見的Web攻擊，它利用用戶已登錄的身份，在用戶毫不知情的情況下，以用戶的名義完成非法操作。

1.CSRF攻擊的原理

下面先介紹一下CSRF攻擊的原理：

技術分享圖片

完成 CSRF 攻擊必須要有三個條件：

  • 用戶已經登錄了站點 A，並在本地記錄了 cookie
  • 在用戶沒有登出站點 A 的情況下（也就是 cookie 生效的情況下），訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A)。
  • 站點 A 沒有做任何 CSRF 防禦

我們來看一個例子： 當我們登入轉賬頁面後，突然眼前一亮驚現"XXX隱私照片，不看後悔一輩子"的鏈接，耐不住內心躁動，立馬點擊了該危險的網站（頁面代碼如下圖所示），但當這頁面一加載，便會執行submitForm這個方法來提交轉賬請求，從而將10塊轉給黑客。

技術分享圖片

2.如何防禦

防範 CSRF 攻擊可以遵循以下幾種規則：

  • Get 請求不對數據進行修改
  • 不讓第三方網站訪問到用戶 Cookie
  • 阻止第三方網站請求接口
  • 請求時附帶驗證信息，比如驗證碼或者 Token

1) SameSite

可以對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨著跨域請求發送，可以很大程度減少 CSRF 的攻擊，但是該屬性目前並不是所有瀏覽器都兼容。

2) Referer Check

HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求時，一般會帶上Referer信息告訴服務器是從哪個頁面鏈接過來的，服務器籍此可以獲得一些信息用於處理。可以通過檢查請求的來源來防禦CSRF攻擊。正常請求的referer具有一定規律，如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。

但在某些情況下如從https跳轉到http，瀏覽器處於安全考慮，不會發送referer，服務器就無法進行check了。若與該網站同域的其他網站有XSS漏洞，那麽攻擊者可以在其他網站註入惡意腳本，受害者進入了此類同域的網址，也會遭受攻擊。出於以上原因，無法完全依賴Referer Check作為防禦CSRF的主要手段。但是可以通過Referer Check來監控CSRF攻擊的發生。

3) Anti CSRF Token

目前比較完善的解決方案是加入Anti-CSRF-Token。即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token，並在服務器建立一個攔截器來驗證這個token。服務器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務。

這種方法相比Referer檢查要安全很多，token可以在用戶登陸後產生並放於session或cookie中，然後在每次請求時服務器把token從session或cookie中拿出，與本次請求中的token 進行比對。由於token的存在，攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token後，其他頁面的表單保存的還是被消耗掉的那個token，其他頁面的表單提交時會出現token錯誤。

4) 驗證碼

應用程序和用戶進行交互過程中，特別是賬戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了用戶的體驗，網站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段，在關鍵業務點設置驗證碼。

三、點擊劫持

點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網站通過 iframe 嵌套的方式嵌入自己的網頁中，並將 iframe 設置為透明，在頁面中透出一個按鈕誘導用戶點擊。

1. 特點

  • 隱蔽性較高，騙取用戶操作
  • "UI-覆蓋攻擊"
  • 利用iframe或者其它標簽的屬性

2. 點擊劫持的原理

用戶在登陸 A 網站的系統後，被攻擊者誘惑打開第三方網站，而第三方網站通過 iframe 引入了 A 網站的頁面內容，用戶在第三方網站中點擊某個按鈕（被裝飾的按鈕），實際上是點擊了 A 網站的按鈕。
接下來我們舉個例子：我在優酷發布了很多視頻，想讓更多的人關註它，就可以通過點擊劫持來實現

iframe {
width: 1440px;
height: 900px;
position: absolute;
top: -0px;
left: -0px;
z-index: 2;
-moz-opacity: 0;
opacity: 0;
filter: alpha(opacity=0);
}
button {
position: absolute;
top: 270px;
left: 1150px;
z-index: 1;
width: 90px;
height:40px;
}
</style>
......
<button>點擊脫衣</button>
<img src="http://pic1.win4000.com/wallpaper/2018-03-19/5aaf2bf0122d2.jpg">
<iframe src="http://i.youku.com/u/UMjA0NTg4Njcy" scrolling="no"></iframe>

技術分享圖片
從上圖可知，攻擊者通過圖片作為頁面背景，隱藏了用戶操作的真實界面，當你按耐不住好奇點擊按鈕以後，真正的點擊的其實是隱藏的那個頁面的訂閱按鈕，然後就會在你不知情的情況下訂閱了。
技術分享圖片

3. 如何防禦

1）X-FRAME-OPTIONS

X-FRAME-OPTIONS是一個 HTTP 響應頭，在現代瀏覽器有一個很好的支持。這個 HTTP 響應頭 就是為了防禦用 iframe 嵌套的點擊劫持攻擊。

該響應頭有三個值可選，分別是

  • DENY，表示頁面不允許通過 iframe 的方式展示
  • SAMEORIGIN，表示頁面可以在相同域名下通過 iframe 的方式展示
  • ALLOW-FROM，表示頁面可以在指定來源的 iframe 中展示

2）JavaScript 防禦

對於某些遠古瀏覽器來說，並不能支持上面的這種方式，那我們只有通過 JS 的方式來防禦點擊劫持了。

<head>
  <style id="click-jack">
    html {
      display: none !important;
    }
  </style>
</head>
<body>
  <script>
    if (self == top) {
      var style = document.getElementById(‘click-jack‘)
      document.body.removeChild(style)
    } else {
      top.location = self.location
    }
  </script>
</body>

以上代碼的作用就是當通過 iframe 的方式加載頁面時，攻擊者的網頁直接不顯示所有內容了。

四、URL跳轉漏洞

定義：借助未驗證的URL跳轉，將應用程序引導到不安全的第三方區域，從而導致的安全問題。

1.URL跳轉漏洞原理

黑客利用URL跳轉漏洞來誘導安全意識低的用戶點擊，導致用戶信息泄露或者資金的流失。其原理是黑客構建惡意鏈接(鏈接需要進行偽裝,盡可能迷惑),發在QQ群或者是瀏覽量多的貼吧/論壇中。
安全意識低的用戶點擊後,經過服務器或者瀏覽器解析後，跳到惡意的網站中。
技術分享圖片

惡意鏈接需要進行偽裝,經常的做法是熟悉的鏈接後面加上一個惡意的網址，這樣才迷惑用戶。
技術分享圖片

諸如偽裝成像如下的網址，你是否能夠識別出來是惡意網址呢？

http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrd
http://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrd
http://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd

2.實現方式：

  • Header頭跳轉
  • Javascript跳轉
  • META標簽跳轉

這裏我們舉個Header頭跳轉實現方式：

<?php
$url=$_GET[‘jumpto‘];
header("Location: $url");
?>
http://www.wooyun.org/login.php?jumpto=http://www.evil.com

這裏用戶會認為www.wooyun.org都是可信的，但是點擊上述鏈接將導致用戶最終訪問www.evil.com這個惡意網址。

3.如何防禦

1)referer的限制

如果確定傳遞URL參數進入的來源，我們可以通過該方式實現安全限制，保證該URL的有效性，避免惡意用戶自己生成跳轉鏈接

2)加入有效性驗證Token

我們保證所有生成的鏈接都是來自於我們可信域的，通過在生成的鏈接裏加入用戶不可控的Token對生成的鏈接進行校驗，可以避免用戶生成自己的惡意鏈接從而被利用，但是如果功能本身要求比較開放，可能導致有一定的限制。

五、SQL註入

SQL註入是一種常見的Web安全漏洞，攻擊者利用這個漏洞，可以訪問或修改數據，或者利用潛在的數據庫漏洞進行攻擊。

1.SQL註入的原理

我們先舉一個萬能鑰匙的例子來說明其原理：

技術分享圖片

<form action="/login" method="POST">
    <p>Username: <input type="text" name="username" /></p>
    <p>Password: <input type="password" name="password" /></p>
    <p><input type="submit" value="登陸" /></p>
</form>

後端的 SQL 語句可能是如下這樣的：

let querySQL = `
    SELECT *
    FROM user
    WHERE username=‘${username}‘
    AND psw=‘${password}‘
`;
// 接下來就是執行 sql 語句...

這是我們經常見到的登錄頁面，但如果有一個惡意攻擊者輸入的用戶名是 admin‘ --，密碼隨意輸入，就可以直接登入系統了。why! ----這就是SQL註入

我們之前預想的SQL 語句是:

SELECT * FROM user WHERE username=‘admin‘ AND psw=‘password‘

但是惡意攻擊者用奇怪用戶名將你的 SQL 語句變成了如下形式：

SELECT * FROM user WHERE username=‘admin‘ --‘ AND psw=‘xxxx‘

在 SQL 中,‘ --是閉合和註釋的意思，-- 是註釋後面的內容的意思，所以查詢語句就變成了：

SELECT * FROM user WHERE username=‘admin‘

所謂的萬能密碼,本質上就是SQL註入的一種利用方式。

一次SQL註入的過程包括以下幾個過程：

  • 獲取用戶請求參數
  • 拼接到代碼當中
  • SQL語句按照我們構造參數的語義執行成功

**SQL註入的必備條件：
1.可以控制輸入的數據
2.服務器要執行的代碼拼接了控制的數據**。
技術分享圖片
我們會發現SQL註入流程中與正常請求服務器類似，只是黑客控制了數據，構造了SQL查詢，而正常的請求不會SQL查詢這一步，SQL註入的本質:數據和代碼未分離，即數據當做了代碼來執行。

2.危害

  • 獲取數據庫信息

    • 管理員後臺用戶名和密碼
    • 獲取其他數據庫敏感信息：用戶名、密碼、手機號碼、身份證、銀行卡信息……
    • 整個數據庫：脫褲
  • 獲取服務器權限
  • 植入Webshell，獲取服務器後門
  • 讀取服務器敏感文件

3.如何防禦

  • 嚴格限制Web應用的數據庫的操作權限，給此用戶提供僅僅能夠滿足其工作的最低權限，從而最大限度的減少註入攻擊對數據庫的危害
  • 後端代碼檢查輸入的數據是否符合預期，嚴格限制變量的類型，例如使用正則表達式進行一些匹配處理。
  • 對進入數據庫的特殊字符（‘，"，，<，>，&，*，; 等）進行轉義處理，或編碼轉換。基本上所有的後端語言都有對字符串進行轉義處理的方法，比如 lodash 的 lodash._escapehtmlchar 庫。
  • 所有的查詢語句建議使用數據庫提供的參數化查詢接口，參數化的語句使用參數而不是將用戶輸入變量嵌入到 SQL 語句中，即不要直接拼接 SQL 語句。例如 Node.js 中的 mysqljs 庫的 query 方法中的 ? 占位參數。

六、OS命令註入攻擊

OS命令註入和SQL註入差不多，只不過SQL註入是針對數據庫的，而OS命令註入是針對操作系統的。OS命令註入攻擊指通過Web應用，執行非法的操作系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險。倘若調用Shell時存在疏漏，就可以執行插入的非法命令。

命令註入攻擊可以向Shell發送命令，讓Windows或Linux操作系統的命令行啟動程序。也就是說，通過命令註入攻擊可執行操作系統上安裝著的各種程序。

1.原理

技術分享圖片
黑客構造命令提交給web應用程序，web應用程序提取黑客構造的命令，拼接到被執行的命令中，因黑客註入的命令打破了原有命令結構，導致web應用執行了額外的命令，最後web應用程序將執行的結果輸出到響應頁面中。

我們通過一個例子來說明其原理，假如需要實現一個需求：用戶提交一些內容到服務器，然後在服務器執行一些系統命令去返回一個結果給用戶

// 以 Node.js 為例，假如在接口中需要從 github 下載用戶指定的 repo
const exec = require(‘mz/child_process‘).exec;
let params = {/* 用戶輸入的參數 */};
exec(`git clone ${params.repo} /some/path`);

如果 params.repo 傳入的是 https://github.com/admin/admin.github.io.git 確實能從指定的 git repo 上下載到想要的代碼。
但是如果 params.repo 傳入的是 https://github.com/xx/xx.git && rm -rf /* && 恰好你的服務是用 root 權限起的就糟糕了。

2.如何防禦

  • 後端對前端提交內容進行規則限制（比如正則表達式）。
  • 在調用系統命令前對所有傳入參數進行命令行參數轉義過濾。
  • 不要直接拼接命令語句，借助一些工具做拼接、轉義預處理，例如 Node.js 的 shell-escape npm包

給大家推薦一個好用的BUG監控工具Fundebug，歡迎免費試用！

參考資料

    • 常見Web 安全攻防總結
    • 前端面試之道
    • 圖解Http
    • Web安全知多少
    • web安全之點擊劫持(clickjacking)
    • URL重定向/跳轉漏洞
    • 網易web白帽子

【轉】常見六大Web 安全攻防解析

相關推薦

【轉】常見六大Web 安全攻防解析

nor 介紹 ech 應用 shel 想要 後端 key 正則表達 原文轉自：https://segmentfault.com/a/1190000018073845 作者：浪裏行舟 在互聯網時代，數據安全與個人隱私受到了前所未有的挑戰，各種新奇的攻擊技術層出不窮。如何

【轉】HTTP學習---Web 緩存

文件的 req one -i com 文件 2.2.3 head 頁面 【原文】https://www.toutiao.com/i6592743068623962632/ 1. 前端緩存概述 前端緩存主要是分為HTTP緩存和瀏覽器緩存。其中HTTP緩存是在HTTP請求傳輸時

【轉】Java中的static關鍵字解析

一、static關鍵字的用途 　　在《Java程式設計思想》P86頁有這樣一段話： 　　“static方法就是沒有this的方法。在static方法內部不能呼叫非靜態方法，反過來是可以的。而且可以在沒有建立任何物件的前提下，僅僅通過類本身來呼叫static方法。這實際上正式static方法的主要用途。”

【轉】Java工具類——資原始檔解析類PropertiesUtil

package com.luang.util.properties;   import java.io.File;   import java.io.FileInputStream;     import java.io.FileOutputStream;    

【轉】【修真院“善良”系列之十八】WEB程序員從零開始到就業的全資料V1.0——只看這一篇就夠了！

absolute feed 自己 session rem 好的 ans 一個 css樣式 這是兩年以來，修真院收集整理的學習資料順序。以CSS15個任務，JS15個任務為基礎，分別依據要完成任務的不同的技能點，我們整理出來了這麽一篇在學習的時候需要看到的資料。這是Versi

嵌入式Linux上通過boa服務器實現cgi/html的web上網【轉】

但是 資料 mail 並發 work 資源 原因 基礎 err 轉自：http://blog.csdn.net/tianmohust/article/details/6595996 版權聲明：本文為博主原創文章，未經博主允許不得轉載。 嵌入式Linux上通

JavaSE--【轉】網絡安全之證書、密鑰、密鑰庫等名詞解釋

detail 發的 都是 base64 request 服務器 win art ive 轉載：http://www.cnblogs.com/alanfang/p/5600449.html 那些證書相關的名詞解釋(SSL,X.509,PEM,DER,CRT,CER,KEY,

文件系統安全【轉】

保存到文件 shm 運維 結果 遞歸 t權限 分別是 pass 完成 一、鎖定系統重要文件 系統運維人員有時候可能會遇到通過root用戶都不能修改或者刪除某個文件的情況，產生這種情況的大部分原因可能是這個文件被鎖定了。在Linux下鎖定文件的命令是chattr，通過這個命令

【轉】CentOS 7.0 安裝Redis 3.2.1詳細過程和使用常見問題

nec count ges des useful 內存 warning before outside http://www.linuxidc.com/Linux/2016-09/135071.htm 環境：CentOS 7.0 Redis 3.2.1 Redis的安裝與啟動

【轉】JMeter學習（二十七）Jmeter常見問題

pre 麻煩 continue 而不是 行為 let 方式 prop 右上角 收集工作中JMeter遇到的各種問題 1. JMeter的工作原理是什麽？ 　　向服務器提交請求；從服務器取回請求返回的結果。 2. JMeter的作用？ 　　JMeter可以用於測試

spring-boot實戰【07】【轉】：Spring Boot中Web應用的統一異常處理

http integer private fin ima lex clas 友好 ref 我們在做Web應用的時候，請求處理過程中發生錯誤是非常常見的情況。Spring Boot提供了一個默認的映射：/error，當處理中拋出異常之後，會轉到該請求中處理，並且該請求有一個全

【轉】用Python建立最簡單的web服務器

web服務 localhost 服務器 pos 根目錄 cal body -m -- 利用Python自帶的包可以建立簡單的web服務器。在DOS裏cd到準備做服務器根目錄的路徑下，輸入命令： python -m Web服務器模塊 [端口號，默認8000]

【轉】web前端到底怎麽學？幹貨資料！

工程師 align develop 不用 ctu blog b前端開發 現實 book 一般據我經驗，在喜歡並且決定和她戀愛之前，我都會做一下充分準備和調查，有必要了解和研究清楚 ‘她’ 的幾個特性和習慣 web前端的基本工作職責 和基礎技能（要清楚） web前端的分類和

【轉】編寫高質量代碼改善C#程序的157個建議——建議68：從System.Exception或其他常見的基本異常中派生異常

base 信息 crypt 滿足 需要 sys sdn private exc 建議68：從System.Exception或其他常見的基本異常中派生異常 微軟建議：從System.Exception或其他常見基本異常之一派生異常。在Visual Studio中輸入Ex

四種常見的POST提交數據方式【轉】

一個 完全 介紹 傳輸 不同 ins http 避免 rac 我們知道，HTTP 協議是以 ASCII 碼傳輸，建立在 TCP/IP 協議之上的應用層規範。規範把 HTTP 請求分為三個部分：狀態行、請求頭、消息主體。類似於下面這樣： <method> <

【轉】【Python】Python發送郵件（常見四種郵件內容）

.cn .com pytho html 常見 body gpo 詳細 tle 感謝：夢琪小生的《【轉】【Python】Python發送郵件（常見四種郵件內容）》 裏面詳細介紹了Python中發送郵件的方法，以供自己參考【轉】【Python】Python發送郵件（常見四種郵件

使用maven創建web項目【轉】

pan 技術分享 south web項目 轉載 javax javaee text comm 1、首先新建一個maven項目，看圖： 2、按照以上步驟就可以創建一個maven項目，可以看到最下圖的目錄結構，但是這樣的目錄結構是不對的，需要做一些

【轉】程序語言的常見設計錯誤(1) - 片面追求短小

body 缺陷 優化 簡單 code 不知道 返回 技巧 兩種 我經常以自己寫“非常短小”的代碼為豪。有一些人聽了之後很贊賞，然後說他也很喜歡寫短小的代碼，接著就開始說 C 語言其實有很多巧妙的設計，可以讓代碼變得非常短小。然後我才發現，這些人所謂的“短小”跟我所說的“短小

【轉】程序語言的常見設計錯誤(2) - 試圖容納世界

常見錯誤 rip 不一定 list 哪裏 code pre asc cti 之前的一篇文章裏，我談到了程序語言設計的一個常見錯誤傾向：片面追求短小，它導致了一系列的歷史性的設計錯誤。今天我來談一下另外一種錯誤的傾向，這種傾向也導致了很多錯誤，並且繼續在導致錯誤的產生。 今天

GridControl常見用法【轉】

解決 綁定 tst add strong 指定 value option xtra 剛接觸DevExpress第三方控件，把GridControl的常見用法整理一下，以供參考： 說明： gcTest GridControl gvText GridVie