User Tag List

+ Trả lời chủ đề
Trang 1/2 12 CuốiCuối
Hiện kết quả từ 1 tới 10 của 12

Chủ đề: Security and ASP

  1. #1
    LionKing
    Guest

    Mặc định

    Summary:
    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web


    Phần 1: An toàn trước khả nǎng bị tấn công CSS (Cross-Site Scripting)

    Phần 2: Ứng dụng có thể không cần sử dụng các cookie thường trực

    Phần 3: Sử dụng SSL cho tất cả các trang nhạy cảm được chuyển trên mạng Internet

    Phần 4: Yêu cầu người sử dụng đang nhập mỗi khi sử dụng ứng dụng

    Phần 5: Log out người sử dụng ra khỏi hệ thống ngay khi họ rời site

    Phần 6: Cắt kết nối khi người sử dụng không tương tác với site trong một khoảng thời gian nhất định

    Phần 7: Ứng dụng không cho phép login đồng thời

    Phần 8: Mã nguồn ứng dụng không chứa chú thích của người phát triển

    Phần 9: Không lưu trữ thông tin kết nối cơ sở dữ liệu trong global.asa

    Phần 10: Các tệp audit log của cơ sở dữ liệu nên ghi nhận tất cả các thay đổi đối với dữ liệu

    Phần 11: Sử dụng các thủ tục lưu sẵn (stored procedure) để truy nhập cơ sở dữ liệu


    Note: Dựa theo 1 số tài liệu

    Xem tiếp ...

  2. #2
    LionKing
    Guest

    Mặc định

    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web


    Phần 1: An toàn trước khả nǎng bị tấn công CSS (Cross-Site Scripting)

    Kiểu tấn công CSS điển hình nhất xảy ra khi tin tặc cố tình chèn một đoạn vǎn bản có chứa script độc hại vào các form nhập dữ liệu. Nội dung nhập vào có thể chứa các thẻ <OBJECT> hoặc &#60;script> cùng các đoạn mã hết sức nguy hiểm.

    Trình duyệt, khi truy nhập site, cho rằng các srcipt này do máy chủ gửi tới, hoàn toàn vô hại nên sẽ chạy nó ở cấp độ bảo mật bình thường, gây ra hậu quả tai hại cho máy tính của người sử dụng .

    Để bảo vệ khỏi bị tấn công theo kiểu CSS, cần chú ý ít nhất những điểm sau:

    - Cập nhập thường xuyên các bản sửa lỗi bảo mật mới nhất của IIS và Windows.

    - Lọc các ky tự đặc biệt do người sử dụng nhập vào như < > " &#39; % ( ) & + -

    - Lọc để loại bỏ các ký tự đặc biệt, kết xuất trên cơ sở thông tin nhập vào của người sử dụng. Xem kỹ các dữ liệu từ:

    + Request.Form Collection
    + Request.QueryString Conllection
    + Request Object
    + Database
    + Cookie
    + Các biến Session và Application


    Để có thể lọc được, cần xác định cụ thể lược đồ mã hoá ký tự trên các trang Web, trong thẻ META, ở phần header. Ví dụ:

    <head> <META http-equiv="Content-Type" Content="text/html; charset=ISO-8859-1">
    </head>

    Xem tiếp ....

  3. #3
    LionKing
    Guest

    Mặc định

    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web

    Phần 2: Ứng dụng có thể không cần sử dụng các cookie thường trực

    - Cookie thường trực là những tệp, được các ứng dụng Web gửi tới máy tính người sử dụng và vẫn tồn tại trên ổ cứng của máy tính ngay cả khi họ không còn duyệt site.

    - Chúng lưu một số thông tin về người sử dụng để các ứng dụng Web tuỳ biến nội dung cho phù hợp với từng đối tượng người sử dụng hoặc cho phép họ bỏ qua giai đoạn đăng ký, đăng nhập (do đã được cung cấp từ trước).

    - Các cookie không thường trực được lưu trong bộ nhớ máy tính của người sử dụng và chỉ tồn tại trong thời gian người sử dụng duyệt site. IIS dựa vào các cookie không thường trực để xác định một phiên ASP. Không có nó, IIS không thể duy trì bất kỳ các thông tin về phiên làm việc, chẳng hạn như các biến phiên.

    - Nếu site của bạn sử dụng cookie thường trực, không nên yêu cầu IIS lưu trữ chúng trong tệp log của IIS. Nếu tệp log lưu lại tất cả các thông tin đăng nhập của người sử dụng thì rất có nhiều khả nǎng, do một thoả hiệp nào đó, những thông tin này có thể được tiết lộ ra ngoài.

  4. #4
    LionKing
    Guest

    Mặc định

    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web

    Phần 3: Sử dụng SSL cho tất cả các trang nhạy cảm được chuyển trên mạng Internet

    - SSL mã hoá nội dung của các thông điệp TCP/IP để nó không bị nhòm ngó trên đường truyền.

    - SSL, hoặc một giải pháp mã hoá khác VPN chẳng hạn, rất cần thiết khi gửi các thông tin nhạy cảm (như số thẻ tín dụng) qua mạng. Cơ hội thâm nhập đường truyền và lấy cắp các thông tin bí mật là thấp song không phải không thể có.

    - Người sử dụng sẽ không đặt niềm tin vào site của bạn nếu các thông tin nhạy cảm không được mã hoá.

    - Tuy nhiên, mặt trái của SSL là làm chậm lại hiệu nǎng thực hiện của ứng dụng. Mức sử dụng tài nguyên hệ thống CPU đòi hỏi trong tiến trình mã hoá và giải mã cho một trang SSL có thể cao hơn từ 10 đến 100% so với các trang không được bình thường.

    - Nếu máy chủ của bạn có lưu lượng các trang SSL cao, bạn có thể phải cân nhắc tới việc sử dụng thêm một bộ tǎng tốc SSL phần cứng.

    Next ....

  5. #5
    LionKing
    Guest

    Mặc định

    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web

    Phần 4. Yêu cầu người sử dụng đăng nhập mỗi khi sử dụng ứng dụng

    - Nguyên tắc này áp dụng cho các ứng dụng có yêu cầu thủ tục đăng nhập. Điều này có nghĩa là việc đăng nhập tự động dựa trên cookie là không được phép.

    - Mặc dù người sử dụng có thể thấy phiền hà nhưng nếu cho họ đăng nhập tự động dựa trên cookie sẽ có rất nhiều nguy hiểm (và như ta đã thấy ở phần trước, sử dụng các cookie thường trực không phải lúc nào cũng phù hợp).

    - Một biện pháp tiếp theo cần thiết để bảo vệ mật khẩu là huỷ tính nǎng Autocomplete của IE trên các trường mật khẩu. Điều này có thể thực hiện bằng cách thêm thuộc tính AUTOCOMPLET ="OFF" cho thẻ <FORM> hoặc <INPUT>. Ví dụ:

    <input type="password" name="pwd" size=16 maxlength=16 AUTOCOMPLETE="OFF">

    Next ....

  6. #6
    LionKing
    Guest

    Mặc định

    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web

    Phần 5. Log out người sử dụng ra khỏi hệ thống ngay khi họ rời site

    - Giả sử một người sử dụng đang xem một trang web trên site của bạn, sau đó họ truy cập một site mới nhưng cuối cùng lại quyết định quay trở lại trang của bạn bằng cách ấn phím BACK.

    - Trong trường hợp này, ứng dụng phải yêu cầu người sử dụng đăng nhập lại một lần nữa. Phát hiện những tình huống tương tự như tình huống vừa rồi của người sử dụng phải dựa hoàn toàn vào các script chạy ở phía trình duyệt mà không thể dựa vào server vì nó không biết người sử dụng đã ở những đâu. Cách giải quyết đầy đủ nhất cho vấn đề này là sử dụng một giải pháp bảo mật Proxy Server như của Netegrity SiteMinder (http://www.netegrity.com). Giải pháp Proxy Server sẽ giám sát mọi yêu cầu Web từ trình duyệt và ghi lại mọi địa chỉ trình duyệt đã truy nhập để ứng dụng có thể kiểm tra.

    - Một cách thức không đầy đủ trong việc kiểm tra các giới hạn site có thể thực hiện bằng cách thiết lập Request.ServerVariables("HTTP_REFERER"). Nếu người sử dụng có gắng truy nhập bất kỳ trang nào khác với trang đăng nhập, từ một URL của một site khác, thì họ sẽ bị từ chối.

    - Tuy nhiên, phương pháp này không thể ngǎn ngừa một người sử dụng rời bỏ site của bạn để tới một site khác nhưng sau đó lại quay trở lại site của bạn và tiếp tục phiên làm của họ.

    Phần này các bạn có thể tham khảo ngay chính Website http://www.bachkhoa.org (Ngay khi bạn mở lại 1 trang đã login bằng tổ hợp phím Ctrl+N thì chắc chắn bạn phải login lại. Tuy nhiên nếu bạn đã login, sau đó chuyển sang trang khác rồi BACK lại thì ....)

    Next .....

  7. #7
    LionKing
    Guest

    Mặc định

    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web

    Phần 6.Cắt kết nối khi người sử dụng không tương tác với site trong một khoảng thời gian nhất định

    - Có 2 giải pháp cho vấn đề này, một giải pháp ở phía máy chủ và một giải pháp sử dụng script ở phía trình duyệt.

    - Giải pháp ở phía máy chủ: Chúng ta sử dụng IIS Managerđặt giới hạn phiên ASP là một khoảng thời gian mong muốn nào đó (giá trị mặc định là 20 phút). Trong ứng dụng, lưu trữ thông tin truy nhập vào một biến phiên làm việc và kiểm tra nó trên mọi trang người sử dụng duyệt qua. Nếu thông tin truy nhập không thuộc về một biến phiên, người sử dụng đã bị cắt kết nối với site và ứng dụng cần định hướng họ sang trang truy nhập hệ thống. Hơn nữa, mặc dù chưa phải có thể tin cậy tuyệt đối, bạn cũng có thể viết mã để xử lý cắt kết nối người sử dụng trong sự kiện session_OnEnd ở tệp Global.asa.

    - Giải pháp phía client sử dụng chút ít JavaScript. Chèn thêm đoạn mã sau vào đầu của mọi trang Web kết xuất bởi ứng dụng:

    &#60;script Language="JavaScript">
    window.setTimeout("window.navigate(&#39;Logout.asp &#39", 900000); </script>

    - &#39;Logout.ASP&#39; là trang để cắt kết nối người sử dụng với ứng dụng. 9000000 là khoảng thời tối đa tính bằng mili giây người sử dụng vẫn duy trì phiên làm việc của họ trong trường hợp không có tương tác nào với site.

    Next ....

  8. #8
    LionKing
    Guest

    Mặc định

    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web

    Phần 7. Ứng dụng không cho phép login đồng thời

    - Yêu cầu này có nghĩa là tại một thời điểm, người sử dụng không thể truy nhập ứng dụng với 2 phiên làm việc khác nhau. Đây cũng là nguyên tắc áp dụng cho phần lớn các ứng dụng client/server và máy trạm khác.

    - Trong môi trường IIS/ASP, việc đáp ứng yêu cầu này không có gì khó khǎn. 2 sự kiện Session_OnStartSession_OnEnd trong Global.asa có thể sử dụng để kiểm tra phiên truy nhập hiện thời của người sử dụng.

    - Bạn cũng có thể áp dụng một giải pháp của cơ sở dữ liệu để huỷ một phiên làm việc đang tồn tại khi một phiên làm việc mới được bắt đầu.


    Next ....

  9. #9
    LionKing
    Guest

    Mặc định

    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web

    Phần 8. Mã nguồn ứng dụng không chứa chú thích của người phát triển

    - Bất cứ cấp bảo mật nào cũng có thể thất bại. Trong những trường hợp khi đã truy nhập được vào các tệp mã nguồn của Website thì những chú thích của người phát triển sẽ là những trợ giúp đắc lực cho tin tặc, nguy hiểm nhất là trong trường hợp mã nguồn có chứa những "viên ngọc" như tên và mật khẩu dùng trong quá trình chạy thử ứng dụng. Yêu cầu này chỉ áp dụng cho những tệp script, chằng hạn như các trang ASP, không áp dụng cho các đoạn mã trong các đối tượng COM đã được biên dịch.

    - Trước đây, những điểm yếu về bảo mật chưa được khắc phục của IIS làm cho các script ASP trên một số site rất dễ bị đọc trộm. Nhiều tin tặc biết rằng họ có thể đọc các script này bằng cách thêm chuỗi "::&#036;DATE" vào cuối yêu cầu truy xuất trang.

    - Để tránh các rủi ro có thể xảy ra, cần loại bỏ mọi chú thích trên trang ASP, HTML hoặc mã JavaScript. Bạn có thể thực hiện bằng tay nhưng cách nhanh nhất là viết một chương trình để loại bỏ các chú thích từ các loại tệp khác nhau.


    Next ............

  10. #10
    LionKing
    Guest

    Mặc định

    Các nguyên tắc bảo mật khi triển khai các ứng dụng Web

    Phần 9. Không lưu trữ thông tin kết nối cơ sở dữ liệu trong global.asa

    - Thông tin kết nối cơ sở dữ liệu gồm tên server, tên cơ sở dữ liệu, thông tin truy nhập SQL Server. Vì là một tệp vǎn bản, những thông tin trong global.asa có thể bị lộ và rơi vào tay những đối tượng sử dụng không đúng mục đích. Những thông tin này nên được lưu trữ ở những nơi khác. Hai cách phổ biến là: lưu trữ nó trong một tệp hoặc trong một Register.

    - Lưu trữ thông tin kết nối cơ sở dữ liệu trong một tệp và sau đó có thể đọc được bằng File System Object hoặc XML Parser là cách an toàn hơn lưu trong global.asa.

    Một giải pháp lưu thông tin trên tệp khác là sử dụng tệp UDL vì nó cho phép lưu tất cả các chi tiết về kết nối. Chuỗi kết nối ADO sẽ trở thành "FILE Name =C:&#092; Path_That_IUSR_<machinename>_Can_Get_To&#092;MyDat aLink.UDL" trong đó tài khoản dịch vụ IIS, IUSR_<machinename>phải có quyền truy nhập để đọc được tệp này.

    - Lưu các thông tin kết nối dưới hình thức được mã hoá trong registry là cách an toàn nhất. Điều này yêu cầu ứng dụng phải viết các thông tin mã hoá vào trong registry và các thành phần COM phải thu về và giải mã nó ở thời gian chạy.

    Đối với IS 5, nếu sử dụng thành phần COM+, còn có một lựa chọn registry khác. COM+ cho phép mỗi thành phần có Constructor được thiết lập trong Component Services Manager. Vì không mã hoá thông tin, cách này cho phép người quản trị site kiểm soát việc truy nhập cơ sở dữ liệu và thay đổi nó vào bất cứ lúc nào.


    Next ............

+ Trả lời chủ đề
Trang 1/2 12 CuốiCuối

Thông tin chủ đề

Users Browsing this Thread

Hiện có 1 người đọc bài này. (0 thành viên và 1 khách)

Chủ đề tương tự

  1. Nên học mcsa security hay học security+?
    Gửi bởi mcsa2007 trong mục Giảng đường khoa ĐTVT
    Trả lời: 0
    Bài cuối: 22-12-2006, 01:57 PM
  2. Một số sách về security and hacking (direct download)
    Gửi bởi Mr.vulh_bk trong mục Tài liệu CNTT
    Trả lời: 31
    Bài cuối: 28-02-2006, 02:34 PM
  3. Bàn về Security in Linux
    Gửi bởi So1 trong mục Các vấn đề CNTT khác
    Trả lời: 10
    Bài cuối: 20-03-2004, 05:51 PM

Từ khóa (Tag) của chủ đề này

Quyền viết bài

  • Bạn không thể gửi chủ đề mới
  • Bạn không thể gửi trả lời
  • Bạn không thể gửi file đính kèm
  • Bạn không thể sửa bài viết của mình


About svBK.VN

    Bách Khoa Forum - Diễn đàn thảo luận chung của sinh viên ĐH Bách Khoa Hà Nội. Nơi giao lưu giữa sinh viên - cựu sinh viên - giảng viên của trường.

Follow us on

Twitter Facebook youtube