Ruby on Rails Security (Phần 1)

1.Introduction

Có rất nhiều frameworks được tạo ra để giúp chúng ta xây dựng các ứng dụng web. Một vài trong số đó có thể giúp chúng ta tăng tính bảo mật cho các ứng dụng web 1 cách dễ dàng. Trên thực tế không có framework nào thiếu an toàn hơn 1 framework khác. Nếu chúng ta sử dụng 1 cách chính xác, chúng ta có thể xây dựng 1 ứng dụng an toàn trên nhiều framework. Rails có 1 số helper method thông minh giúp chúng ta làm việc đó, ví dụ như chống lại SQL injection.

Tuy nhiên, không có kiểu bảo mật plug-n-play. Việc bảo mật phụ thuộc vào người sử dụng framwork,. Nó phụ thuộc vào tất cả các layer của web application environment: back-end storage, web server và chính ứng dụng web(có thể là các layer khác nữa)

Tuy nhiên, Gartner Group ước tính rằng 75% các vụ tấn công đang ở tầng ứng dụng web và phát hiện ra rằng "trong số 300 trang web được kiểm tra, 97% dễ bị tấn công". Điều này là do các ứng dụng web tương đối dễ tấn công, vì chúng rất dễ hiểu và vận dụng, ngay cả bởi người không có nhiều kinh nghiệm.

Các mối đe dọa ứng dụng web bao gồm chiếm tài khoản người dùng (account hijacking), bỏ qua kiểm soát truy cập (bypass of access control), đọc hoặc sửa đổi dữ liệu nhạy cảm (reading or modifying sensitive data), đặt fraudulent content (presenting fraudulent content). Hoặc kẻ tấn công có thể cài đặt chương trình Trojan horse hoặc phần mềm gửi email không mong muốn, nhằm mục đích tài chính hoặc gây thiệt hại thương hiệu bằng cách sửa đổi tài nguyên của công ty. Để ngăn chặn các cuộc tấn công, giảm thiểu tác động của họ và loại bỏ các cuộc tấn công, trước hết bạn phải hiểu đầy đủ các phương pháp tấn công để tìm ra biện pháp đối phó chính xác. Đó là mục đích của bài viết này.

Chúng ta bắt đầu từ 1 nơi đặc biệt dễ bị tấn công:

2.Sessions

2.1 What are Sessions?

Hầu hết các ứng dụng đều cần theo dõi trạng thái của một người dùng cụ thể. Đây có thể là nội dung của giỏ hàng hoặc id người dùng của người dùng đang đăng nhập. Không có ý tưởng về session, người dùng sẽ phải xác định, và có thể chứng thực, trên mọi request. Rails sẽ tự động tạo ra một session mới nếu người dùng mới truy cập ứng dụng. Nó sẽ load một session hiện có nếu người dùng đã sử dụng ứng dụng.

Một session thường bao gồm một hash của các value và một ID session, thường là một chuỗi 32 ký tự, để xác định các hash. Mỗi cookie được gửi đến trình duyệt của khách hàng bao gồm ID session. Và ngược lại: trình duyệt sẽ gửi nó đến máy chủ theo yêu cầu từ khách hàng. Trong Rails bạn có thể lưu và lấy các giá trị sử dụng phương thức session:

session[:user_id] = @current_user.id
User.find(session[:user_id])

2.2 Session ID

ID session là một chuỗi hex ngẫu nhiên gồm 32 ký tự được tạo ra bằng cách sử dụng SecureRandom.hex tạo ra một chuỗi hex ngẫu nhiên sử dụng các phương pháp nền tảng cụ thể (như OpenSSL, / dev / urandom hoặc Win32) để tạo ra các số ngẫu nhiên.

2.3 Session Hijacking

Ăn cắp session ID của người dùng cho phép kẻ tấn công sử dụng ứng dụng web bằng tên nạn nhân.

Nhiều web app sử dụng 1 hệ thống authentication: người dùng cung cấp tên người dùng và mật khẩu, ứng dụng web kiểm tra và lưu trữ id người dùng tương ứng trong session hash. Từ đó session này là hợp lệ. Trên mỗi request, ứng dụng sẽ dựa vào session mà không cần lượt chứng thực mới. Session ID trong cookie sẽ xác định session.

Do đó, cookie phục vụ như là xác thực tạm thời cho các ứng dụng web. Bất cứ ai nắm lấy một cookie từ người khác, có thể sử dụng ứng dụng web như người dùng này - với những hậu quả nghiêm trọng có thể xảy ra. Dưới đây là một số cách để chiếm quyền kiểm soát session và các biện pháp đối phó của họ:

• Sniff cookie trong một mạng không an toàn. Một mạng LAN không dây có thể là một ví dụ của một network như vậy. Trong một mạng LAN không dây không được mã hóa, đặc biệt dễ dàng để kiểm soát các traffic truy cập của tất cả các khách hàng kết nối. Đối với người xây dựng ứng dụng web, điều này có nghĩa là cung cấp kết nối an toàn qua SSL. Trong Rails 3.1 và mới hơn, điều này có thể được thực hiện bằng cách luôn luôn buộc kết nối SSL trong tệp tin cấu hình ứng dụng của bạn:

config.force_ssl = true

• Hầu hết mọi người không xóa cookie sau khi làm việc tại network công cộng (như quán net chẳng hạn). Vì vậy, nếu người dùng cuối không đăng xuất khỏi ứng dụng web, bạn sẽ có thể sử dụng nó như người dùng này. Để hạn chế điều này chúng ta nên cung cấp cho người dùng nút đăng xuất trong ứng dụng web và làm nó trở nên nổi bật.

• Các cuộc tấn công cross-site scripting (XSS) nhằm khai thác cookie của người sử dụng. Chúng ta sẽ tìm hiểu thêm về XSS sau.

• Thay vì ăn cắp cookie không xác định được đối với kẻ tấn công, họ sẽ sửa user's session identifier (trong cookie) mà họ biết. Đây được gọi là session fixation.