Giới thiệu ASP.NET FormsAuthentication potx

Báo cáo nghiên cứu công nghệ Báo cáo số 05 Giới thiệu ASP.NET FormsAuthentication Hiep Nguyen Van Hanoi, 22.10.2010 Abstract Vào thời điểm viết bài này, các chuyên gia vừa phát hiện lỗ hổng bảo mật trong module đăng nhập của ASP.NET. Điểm yếu bị khai thác thành công là việc ASP.NET dùng mã hóa khối CBC (với key là giá trị trong thẻ Machine key của file web.config) để mã hóa thông tin trong module đăng nhập. Kẻ tấn công, bằng việc gửi dồn dập nhiều request tới server, căn cứ trên các response mà tìm ra được key dùng trong mã hóa khối. Từ đó dễ dàng giải mã được thông tin trao chuyển giữa client và server. Microsoft ngay lập tức đã cung cấp bản vá cho lỗi nghiêm trọng này. Sự kiện này dẫn người đọc quan tâm tới câu hỏi: cơ chế hoạt động trong module đăng nhập của ASP.NET như thế nào và làm sao tăng cường bảo mật? Những nội dung trình bày tiếp theo nhằm giới thiệu 1 trong những cơ chế phổ biến, ASP.NET FormsAuthentication, trong đó tập trung vào khía cạnh tăng cường bảo mật cho cơ chế này. Introduction Đầu tiên, xin nhắc lại cơ chế xử lý khi có 1 request gửi đến ASP.NET Engine (nếu bạn là dân pro ASP.NET thì có thể bỏ qua phần này) Hình 1. Xử lý request với IIS và ASP.NET Khi 1 request được gửi đến, nó buộc phải đi qua các HTTP module được khai báo trong ASP.NET Engine. Các http module này can thiệp vào thông tin trong request để xử lý. Bạn có thể tự viết 1 vài HTTP module và khai báo vào web.config trong website của mình, ví dụ như module filter dùng để lọc từ khóa nhạy cảm(delete, insert, update), lọc dấu nháy 1 Báo cáo nghiên cứu công nghệ Báo cáo số 05 Tiếp theo request được chuyển tới HTTP Handler tương ứng. Ở mức ứng dụng, bạn có thể chỉ định sử dụng Handler nào, ví dụ trong ASP.NET MVC sử dụng MvcHttpHandler thay cho HttpHandler mặc định của ASP.NET. Session State Có 1 HTTP module quan trọng đó là SessionStateModule. ASP.NET dùng 1 chuỗi định danh 120 bit để xác định mỗi session. Chuỗi này được sinh ra bằng thuật toán đặc biệt, đảm bảo là ngẫu nhiên và phân biệt, khiến kẻ tấn công khó đoán được sessionID cấp cho client. Trong gói tin client gửi lên server có chứa sessionID, server sẽ tìm trong state server (bao gồm 1 tập hợp các dữ liệu đã serialize) 1 thành phần có ID tương ứng, sau đó convert thành object session để sử dụng. Mỗi lần client tạo 1 request mới, ASP.NET luôn tạo 1 sessionID mới, cho đến khi client thực sự dùng session state để lưu dữ liệu (ví dụ khi user đăng nhập sẽ lưu username vào session state HttpContextBase.User.Identity.IsAuthenticated). Đến khi có dữ liệu lưu trong session thì sessionID không được tạo mới sau mỗi request nữa (từ lúc này sessionID được giữ cố định). SessionStateModule nêu trên có nhiệm vụ sinh ra chuỗi sessionID ứng với request của client, đồng thời thực hiện truy xuất dữ liệu ứng với sessionID dựa trên Session State Provider và gắn dữ liệu đó lên context của request. SessionID được gửi ở dạng clear text, là 1 phần của cookie hoặc đối với trình duyệt không bật cookie thì là 1 phần của URL. Vấn đề đặt ra là do sessionID lưu trong session state của server và trong cookie ở phía client, nên có khả năng bị ăn cắp và giả mạo cookie. Một số phương pháp thường được sử dụng để ngăn chặn như: dùng 1 session module kiểm tra sự thay đổi địa chỉ IP của client hoặc chỉ sử dụng session cookie một cách giới hạn (chỉ dùng trong các phạm vi của website có mã hóa TLS/SSL) v.v. FormsAuthentication Ticket và cookie Ticket được dùng bởi Forms Authentication trên server để xác minh 1 user đã đăng nhập. nếu ta chọn sử dụng form authentication không có cookie (bởi nhiều trình duyệt block cookie) thì ticket sẽ được mã hóa và gắn vào URL. Nói chung ticket được dùng để báo cho server biết bạn là ai. Ticket được mã hóa và ký, sử dụng giá trị của thẻ machineKey trong web.config. ASP.NET 2.0 dùng decryptionKey và thuộc tính decryption của thẻ machineKey để mã hóa FormsAuthentication Ticket.Thuộc tính decryption chỉ rõ thuật toán mã hóa được dùng .Việc giả mạo (tampering) ticket sẽ gây lỗi giải mã ở server khiến user bị chuyển tới trang đăng nhập. Bạn có thể tạo form authentication ticket để sử dụng trong mục đích cụ thể. Đối với non-persistent cookie, khi ticket hết hạn thì cookie cũng hết hạn. Với FormsAuthentication không có cookie thì khi đóng trình duyệt, ticket bị xóa và được tạo lại vào request tiếp theo. Protect FormsAuthentication 2 Báo cáo nghiên cứu công nghệ Báo cáo số 05 Ticket được tạo khi user đăng nhập và được biểu diễn cho authenticated user. Trình duyệt gửi ticket này cùng với những request của cùng session đó tới server. Yêu cầu đặt ra là phải bảo mật ticket này. Một số điểm yếu có thể bị khai thác • Elevation of privileges o kẻ tấn công có thể cập nhật user name hoặc list role chứa trong ticket trước khi gửi nó về server • Session hijacking: o kẻ tấn công ăn cắp ticket của người khác  ví dụ sử dụng XSS cross site scripting o hoặc do giao dịch không được bảo mật, ví dụ không sử dụng SSL Secure Socket Layer o hoặc ticket được lưu trong browser cache dễ bị đánh cắp • Session usage after signout: o sau khi user log out, ticket vẫn có giá trị cho đến khi TTL(time-to-live) của nó hết hạn o kẻ tấn công có thể dùng ticket loại này để giả mạo user • Eavesdropping (nghe lén) o kẻ tấn công có thể phân tích 1 ticket và lấy được các thông tin nhạy cảm và dùng nó để làm tổn hại hệ thống • Làm tổn hại user identity store o kẻ tấn công truy nhập được vào user identity store có thể biết được user name, password; hoặc dùng SQLi trực tiếp truy nhập data store Giải pháp đề xuất • Hashed MACs (HMACs) o dùng SHA1 hoặc MD5 làm chứng cớ chống giả mạo o SHA1 được đánh giá cao hơn MD5 vì tạo ra hash size lớn hơn • Mã hóa o Dùng AES symetric encryption o AES được đánh giá hơn DES và 3DES vì key size của nó lớn hơn • Giới hạn thời gian tồn tại Session o giảm time window (round trip time) o khiến kẻ tấn công khó có thể dùng ticket giả mạo • Giao dịch thông qua HTTPS o ngăn kẻ tấn công xem hoặc sửa ticket khi nó được chuyển trong mạng Một số thao tác quan trọng thực hiện giải pháp Thiết lập trong file web.config • <forms protection=”All”> • SHA1 và AES (Hashed MACs – Message Authentication Code) o <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" 3 Báo cáo nghiên cứu công nghệ Báo cáo số 05 decryption="Auto" validation="SHA1" /> o SHA1: hàm băm o AES: mã hóa o Chú ý : thiết lập này dành cho single server deployment. Đối với web farm deployment bạn cần phải tạo machine key thủ công, đồng thời đưa lên các server  tham khảo thêm về lớp tiện ích dùng sinh key trong link sau  http://msdn.microsoft.com/en-us/library/ms998288.aspx • IsolateApps : o Đảm bảo các ứng dụng được host cùng server không thể ảnh hưởng đến ứng dụng khác (web application) o nên disable redirect cross-application o Thiết lập <forms EnableCrossAppRedirects = false> • Bảo mật Ticket dùng SSL o chú ý giao thức bắt tay làm tăng network traffic o <forms loginUrl="Secure\Login.aspx" requireSSL="true" /> o với thiết lập này trang đăng nhập phải dùng với url dạng https o Chú ý: nếu đang dùng cookieless session, thì phải luôn đảm bảo ticket được bảo mật Một số thao tác khác tăng cường bảo mật FormsAuthentication Bao gồm • Phân chia website • Không giữ FormsAuthentication cookie • Giảm ticket timelife • Dùng slidingExpiration • Chính sách quản lý user • Độ mạnh mật khẩu • Validate dữ liệu hiệu quả • Dùng name và path cookie khác nhau • Đặt cookie xác thực và cookie chứa thông tin cá nhân tách biệt • Dùng URL tuyệt đối để chuyển vị trí Cụ thể • Phân chia website Bước 1 o có thể không cần thiết phải đặt SSL cho mọi page o đặt những page cần bảo mật vào 1 thư mục riêng trong IIS o sau đó config thư mục này yêu cầu SSL (vd thư mục Secure), sẽ set AccessSSL= true trong IIS Metabase Bước 2 o dùng <authorization> để đảm bảo chỉ có user authenticated mới được truy nhập thư mục này 4 Báo cáo nghiên cứu công nghệ Báo cáo số 05  <! The secure folder is for authenticated and SSL access only. >  <location path="Secure" > • <system.web> o <authorization>  <deny users="?" /> o </authorization> • </system.web>  </location> Bước 3 o cần cho phép user chưa đăng nhập có thể vào những page ở thư mục gốc của ứng dụng  <system.web>  <! The virtual directory root folder contains general pages. Unauthenticated users can view them and they do not need to be secured with SSL. > • <authorization> o <allow users="*" /> • </authorization>  </system.web> • Không giữ FormsAuthentication cookie o không giữ FA cookie, bởi nó được lưu ở máy client và có thể bị đánh cắp o FormsAuthentication.SetAuthCookie(username, false /*isPersistentCookie*/) • Giảm ticket timelife o giảm thời gian cookie timeout: từ đó giảm thời gian kẻ tấn công có thể dùng để truy nhập thông qua việc giả mạo  <forms timeout="10" slidingExpixration="true" /> • Dùng slidingExpiration o slidingExpiration="false": có thể là cứ sau 1 khoảng thời gian là thì reset (bất kể client có gửi request hay không) o slidingExpiration="true": the expiration period được reset sau mỗi request (tức là client mà gửi request lên server thì thời gian này được reset lại, quá thời gian đó mà không có kết nối thì sẽ timeout) o chú ý khác biệt giữa timeout này ở client và session time out ở server • Chính sách quản lý user o mật khẩu không chứa 1 phần user name o mật khẩu ít nhất 6 kí tự o mật khẩu chứa ký tự từ 3 trong 4 nhóm  chữ hoa  chữ thường  số  ký tự đặc biệt o Yêu cầu đổi mật khẩu định kỳ 5 Báo cáo nghiên cứu công nghệ Báo cáo số 05  cần lưu lại mật khẩu cũ  cần có bước ngăn user dùng lại mật khẩu cũ o Trong connection string không nên lưu username và password; thực tế connection string cần được mã hóa o Đối với mật khẩu cần dùng salt và hàm băm 1 chiều o Giới hạn user thông thường không thể được phép truy nhập trực tiếp vào dữ liệu trong data store o Sử dụng các role khác nhau trong database, phân quyền truy nhập tới các dữ liệu nhạy cảm • Độ mạnh mật khẩu o SQL Membership Provider  config provider để tăng độ mạnh o Provider: các provider mặc định thường được khai báo trong file config o SQL Membership Provider  dùng connection string riêng  custom Membership Provider o Active Directory Provider o Dùng Regex: biểu thức chính quy o có thể dùng control CreateUserWizard • Validate dữ liệu hiệu quả o chống XSS, SQLi o ValidateRequest  <%@ Page Language="c#" Codebehind="LoginForm.aspx.cs" ValidateRequest="true" %> o FA cookie: đánh dấu là HttpOnly, để ngăn không cho truy cập bằng client-side script o Disable những lệnh HTTP không dùng: TRACE, OPTIONS o Tránh tạo truy vấn động bằng cách ghép các xâu input, nên dùng store procedure • Dùng name và path cookie khác nhau o dùng name và path khác nhau  <forms name="YourAppName" path="/FormsAuth" />  ngăn chặn nguy cơ khi host nhiều ứng dụng trên cùng server o cookieless session: thường ẩn chứa lỗi vì ticket không được bảo vệ bởi cơ chế requireSSL và HttpOnly  khuyến cáo dùng cookie cho ticket, thay vì dùng query string • Đặt cookie xác thực và cookie chứa thông tin cá nhân tách biệt o Cần tách riêng ra, bởi tính chất của 2 loại cookie là khác nhau 6 Báo cáo nghiên cứu công nghệ Báo cáo số 05 • Dùng URL tuyệt đối để chuyển vị trí o vấn đề trong 1 ứng dụng có cả http, https o khi chuyển giữa các trang thì 1redirect luôn dùng protocol của trang hiện tại, chứ không phải trang đích o thay vì dùng kiểu “ \publicpage.aspx”  nên dùng url đầy đủ : http://servername/appname/publicpage.aspx o tương tự khi chuyển ngược lại từ http  https Conclusion Báo cáo này tập trung vào trình bày cơ chế FormsAuthentication sử dụng trong các module đăng nhập của ASP.NET và một số biện pháp tăng cường bảo mật. 7 Báo cáo nghiên cứu công nghệ Báo cáo số 05 References [1] Pro ASP.NET 4 [2] http://support.microsoft.com/kb/899918 [3] http://msdn.microsoft.com/en-us/library/ms998310.aspx 8 . 05 Giới thiệu ASP. NET FormsAuthentication Hiep Nguyen Van Hanoi, 22.10.2010 Abstract Vào thời điểm viết bài này, các chuyên gia vừa phát hiện lỗ hổng bảo mật trong module đăng nhập của ASP. NET. . trong module đăng nhập của ASP. NET như thế nào và làm sao tăng cường bảo mật? Những nội dung trình bày tiếp theo nhằm giới thiệu 1 trong những cơ chế phổ biến, ASP. NET FormsAuthentication, trong. lại cơ chế xử lý khi có 1 request gửi đến ASP. NET Engine (nếu bạn là dân pro ASP. NET thì có thể bỏ qua phần này) Hình 1. Xử lý request với IIS và ASP. NET Khi 1 request được gửi đến, nó buộc phải