Helpex - Trao đổi & giúp đỡ Đăng nhập
12

Có thể tiêu đề bị diễn đạt không tốt nhưng không thể nghĩ ra cách nói hay hơn.

Tôi đang làm việc trên một hệ thống đăng nhập vào lúc này (không có gì chính thức, chỉ đang thử nghiệm) và đang lên kế hoạch sử dụng PHPLiveX (một thư viện AJAX) cho một số tính năng. Về cơ bản, bạn tạo một số hàm PHP sau đó được gọi thông qua JavaScript. Bạn có thể thêm các tham số (getElementById) vào JavaScript được chuyển sang hàm PHP.

Điều tôi thực sự muốn biết là liệu có an toàn hay không nếu chỉ gọi hàm từ JavaScript mà không mã hóa mật khẩu trước, sau đó để hàm PHP mã hóa nó (SHA256 trong trường hợp này). Dữ liệu được truyền qua AJAX có thể bị chặn không? Nếu vậy thì khả năng này là như thế nào?

12 hữu ích 5 bình luận 11k xem chia sẻ
13 trả lời 13
46

Không an toàn hơn hoặc kém an toàn hơn yêu cầu HTTP POST thông thường do trình duyệt đưa ra (như trong từ a <form>)

"Bản sửa lỗi" cho điều này cũng giống như "bản sửa lỗi" cho các yêu cầu không phải AJAX - sử dụng SSL.

46 hữu ích 3 bình luận chia sẻ
21

Như những người khác đã đề cập, không nguy hiểm hơn việc gửi một bài đăng HTTP từ một biểu mẫu. Trên thực tế, đó là một điều rất giống nhau.

Nhưng nếu HTTPS không phải là một tùy chọn, bạn luôn có thể sử dụng lược đồ thử thách / phản hồi qua kết nối không được mã hóa. Về cơ bản nó hoạt động như thế này:

  • Máy chủ có hàm băm SHA (hoặc bất kỳ thuật toán băm nào bạn thích) cho mật khẩu của người dùng.
  • Khách hàng có mật khẩu.
  • Ứng dụng khách yêu cầu (sử dụng AJAX không được mã hóa) mà máy chủ gửi một thử thách (một chuỗi byte ngẫu nhiên; ký tự là được.)
  • Máy chủ tạo một thử thách và một ID thử thách, và lưu nó khi hết hạn.
  • Khách hàng nhận được thử thách và ID thử thách.
  • Máy khách băm mật khẩu bằng SHA.
  • Ứng dụng băm băm kết quả băm với thử thách được thêm vào theo một cách nào đó.
  • Khách hàng gửi ID thử thách (không phải chính thử thách) và hàm băm kết quả thứ hai.
  • Máy chủ tra cứu thử thách bằng ID nếu nó tồn tại và chưa hết hạn.
  • Máy chủ gắn thử thách vào hàm băm mật khẩu được lưu trữ và tạo một hàm băm bằng cách sử dụng cùng một lược đồ với máy khách.
  • Máy chủ so sánh hàm băm của nó với máy khách. Nếu nó giống nhau, người dùng đã được xác thực.

Nó thực sự khá đơn giản để thiết lập khi bạn có ý tưởng. Wikipedia có một số thông tin bổ sung về nó.

CHỈNH SỬA: Tôi nhận thấy rằng tôi đã quên đề cập, cho dù xác thực thành công hay không, bạn phải xóa thử thách, bất kể. Việc cho khách hàng thử nhiều lần trong một thử thách có thể dẫn đến các vấn đề bảo mật.

21 hữu ích 5 bình luận chia sẻ
7

Cho dù bạn đang gửi mật khẩu qua AJAX hay qua biểu mẫu thông thường, nó vẫn được gửi qua một POSTyêu cầu HTTP (hy vọng). Vì vậy, bạn không thêm hoặc bớt bất cứ điều gì bảo mật một cách khôn ngoan.

Cách duy nhất để ngăn ai đó chặn mật khẩu của bạn là sử dụng SSL (thông qua AJAX hoặc không).

7 hữu ích 0 bình luận chia sẻ
1

Điều này cũng an toàn như khi có một biểu mẫu đăng nhập không được bảo mật SSL được gửi qua đường dây, giống như hầu hết các diễn đàn ngoài kia đều làm vậy!

1 hữu ích 0 bình luận chia sẻ
1

Đảm bảo rằng mục tiêu của lệnh gọi AJAX của bạn là trang HTTPS: // đáng tin cậy và bạn đã thực hiện nó an toàn từng chút một như bất kỳ trang nào khác gửi cùng một thông tin mà phần còn lại của ứng dụng của bạn đang thực hiện. Hầu hết các thư viện / khuôn khổ không giới hạn bạn chỉ HTTP: // cho các lệnh gọi AJAX của bạn.

1 hữu ích 0 bình luận chia sẻ
1

Có, nó có thể được đọc. Cũng giống như mọi thứ khác mà không có một số loại lớp bảo mật (Xem SSL)

Để xem nó, hãy tự chạy một công cụ như WireShark khi bạn thực hiện các lệnh AJAX của mình.

Làm thế nào có thể? Không hẳn, nhưng mật khẩu của người dùng có thể sẽ được lưu trong tệp nhật ký của ai đó ở dạng văn bản thuần túy. Nếu ai đó cuối cùng tìm thấy nó, thì đó có thể là một tin xấu. Trở lại trường đại học, lớp học mạng của tôi có quyền truy cập vào một số bộ định tuyến (bán) ưa thích. Chúng tôi đã có nhiệm vụ đăng ký tài khoản trên các trang web ngẫu nhiên. Khi chúng tôi làm điều này, chúng tôi nhận thấy một số điều rất đáng sợ trên các tệp nhật ký trong bộ định tuyến. Đây là một điều mở mang tầm mắt cho tôi khi nghĩ về cách mọi giao tiếp được theo dõi và rất có thể được ghi lại ở đâu đó.

1 hữu ích 0 bình luận chia sẻ
1

Các cuộc gọi AJAX chỉ là một yêu cầu HTTP đơn giản.

Nó hoạt động giống như yêu cầu HTTP thông thường và cũng đi kèm với tất cả những ưu điểm và nhược điểm của nó. Nó không phải là bất kỳ an toàn hơn.

Để thực hiện các cuộc gọi AJAX của bạn an toàn, có một số cách bạn có thể thử:

  1. Sử dụng SSL. SSL sẽ mã hóa các tin nhắn giữa người dùng và máy chủ của bạn. Nhược điểm của SSL là bạn sẽ phải trả thêm phí cho các chứng chỉ SSL hợp lệ. Chứng chỉ SSL không hợp lệ trong khi có thể sử dụng được, không cung cấp cùng một mức độ đảm bảo bảo mật cho người dùng.
  2. Mã hóa các yêu cầu trước khi được gửi, phía máy khách. Ví dụ: băm mật khẩu của người dùng trước khi được gửi qua mạng. Hầu hết thời gian, bạn không cần mật khẩu văn bản thuần túy của người dùng. Điều này không thể sử dụng được khi người dùng không cho phép chạy tập lệnh phía máy khách.
  3. Và ngoài những thông tin sai lệch phổ biến cho rằng POST an toàn hơn GET, thì không. Cả hai đều mở như nhau cho những kẻ tấn công nhìn thấy.
1 hữu ích 5 bình luận chia sẻ
0

Bạn đang gửi nó một cách rõ ràng, vì vậy bất kỳ ai có khả năng dò tìm / nghe / vv trong mạng của khách hàng sẽ có thể dễ dàng nhìn thấy mật khẩu. Cuộc gọi AJAX chỉ là một thông báo HTTP cũ đơn thuần. Nếu bạn muốn thấy điều này trong hoạt động, hãy tạo một bản sao của wirehark và tự yêu cầu. Bạn sẽ có thể thấy mật khẩu trong gói HTTP.

0 hữu ích 0 bình luận chia sẻ
0

Như đã đề cập, SSL là giải pháp tốt nhất ở đây. Tuy nhiên, bạn có thể băm mật khẩu ở phía máy khách. Nếu bạn google cho nó, bạn sẽ tìm thấy rất nhiều triển khai javascript của md5.

0 hữu ích 0 bình luận chia sẻ
0

Nó không an toàn. Không gửi mật khẩu không được mã hóa. Rất có thể một lúc nào đó chúng sẽ bị chặn lại, bạn sẽ gặp rắc rối lớn.

Đây là một ví dụ video về việc lấy mật khẩu telnet. Telnet gửi văn bản thuần túy và điều này minh họa một cách độc đáo vấn đề chính mà bạn gặp phải nếu bạn thậm chí nghĩ đến việc này. Bất kỳ đứa trẻ tập lệnh hai bit nào cũng có thể lấy một mật khẩu văn bản thuần túy nhanh hơn bạn có thể, vì vậy "Ôi Chúa ơi, cơ sở dữ liệu của tôi đã đi đâu?"

0 hữu ích 1 bình luận chia sẻ
0

Mật khẩu văn bản thuần túy được truyền qua AJAX sẽ an toàn như mật khẩu tương tự được truyền qua một bài đăng HTTP thông thường. Điều đó có nghĩa là AJAX sử dụng HTTP và do đó có thể bị chặn và đánh hơi. Đặt cược tốt nhất của bạn là sử dụng HTTPS (SSL).

Để đọc thêm về AJAX và bảo mật, tôi khuyên bạn nên đọc các bài đọc sau

0 hữu ích 0 bình luận chia sẻ
0

chết tiệt các bạn làm tôi lo lắng. SSL không bảo vệ khỏi cuộc tấn công MITM nhiễm độc arp. Sẽ rất nguy hiểm nếu tôn thờ SSL như các bạn. Bạn phải có một cách để mã hóa mật khẩu ở phía máy khách trước khi nó thực hiện dù chỉ một bước hoặc nếu không thì ngay cả một hacker mới vào nghề cũng có thể đánh chặn mật khẩu ở dạng bản rõ

0 hữu ích 1 bình luận chia sẻ
0

Người ta cũng nên biết rõ về các lỗ hổng bảo mật tiềm ẩn khi xây dựng một ứng dụng sử dụng Ajax.

Trang web sau đây có một số thông tin thực sự tốt liên quan đến các cuộc tấn công Ajax và XSS hoặc XSRF http://www.isecpartners.com/files/isec-attacking_ajax_application.bh2006.pdf

Đừng quên rằng khi bạn thực hiện một hàm từ xa có thể truy cập vào lệnh gọi javascript, người dùng có thể chỉ cần đoán lệnh gọi hàm và sửa đổi nó để thực hiện đặt giá thầu của mình.

0 hữu ích 0 bình luận chia sẻ
loading
Không tìm thấy câu trả lời bạn tìm kiếm? Duyệt qua các câu hỏi được gắn thẻ php ajax security authentication login , hoặc hỏi câu hỏi của bạn.

Có thể bạn quan tâm

loading