🔏Authentication vulnerabilities

Server Side Vul

Note: Sau khi đọc xong bài này mọi người có thể quay lại đọc bài Host Header Attack này

Về mặt khái niệm, lỗ hổng xác thực là một số vấn đề đơn giản nhất để hiểu. Tuy nhiên, chúng có thể là một trong những yếu tố quan trọng nhất do mối quan hệ rõ ràng giữa xác thực và bảo mật. Ngoài việc có khả năng cho phép kẻ tấn công truy cập trực tiếp vào dữ liệu và chức năng nhạy cảm, chúng cũng để lộ bề mặt tấn công bổ sung để khai thác thêm. Vì lý do này, học cách xác định và khai thác các lỗ hổng xác thực, bao gồm cả cách vượt qua các biện pháp bảo vệ thông thường, là một kỹ năng cơ bản.

Authentication là gì

Note: token: mã thông báo

Authentication là quá trình xác thực danh tính của người dùng hoặc khác hàng nhất định.

Authenticatipn có thể dựa vào các nhóm yếu tố(factors) bao gồm:

• Somthing you know: như password hoặc câu trả lời cho câu hỏi bảo mật. Đôi khi chúng được gọi là yếu tố kiến thức.

• Something you have: Như số điện hoặc hoặc security token. Đôi khi chúng được gọi là yếu tố chiếm hữu

• Somthing you are or do: Ví dụ như sinh trắc học(biometrics) của bạn như vân tay... hoặc yếu tố hành vi. Đôi khi nó được gọi là yếu tố vốn có.

Authentication khác gì so với Authorization

Chỉ cần nhìn vào nghĩa đen của nó thì một bên là xác thực, một bên là ủy quyền.

và Authorization là hai quy trình bảo mật thông tin quan trọng mà admin sử dụng để bảo vệ hệ thống thông .

Authentication là quá trình xác minh danh tính của người dùng hoặc dịch vụ dựa trên thông tin này thì hệ thống sẽ cung cấp cho người dùng quyền truy cập thích hợp.

Authorization là quá trình bảo mật xác định mức độ truy cập của người dùng hoặc dịch vụ.

Liên quan đến Authentication vs Authorization, còn một yếu tố khác cũng không kém phần quan trọng cần lưu ý là Session Management. Đây có thể xem là chất keo liên kết phần Authentication với Authorization/Access Control để bảo đảm duy trì thông tin đã xác thực cho những phiên hoạt động tiếp theo đúng quyền hạn và nghĩa vụ.

Lỗ hổng Authentication phát sinh như thế nào

Nói chung, hầu hết các lỗ hổng trong cơ chế xác thực phát sinh theo một trong hai cách:

• Các cơ chế xác thực yếu vì chúng không bảo vệ được đầy đủ trước các cuộc tấn công brute-force.

• Các lỗ hổng logic hoặc mã hóa kém trong quá trình thực hiện cho phép kẻ tấn công bỏ qua hoàn toàn các cơ chế xác thực. Điều này đôi khi được gọi là "xác thực bị hỏng".

Hậu quả của lỗ hổng Authentication là gì

Tác động của các lỗ hổng xác thực có thể rất nghiêm trọng. Một khi kẻ tấn công đã bỏ qua xác thực hoặc đã cưỡng ép xâm nhập vào tài khoản của người dùng khác, chúng sẽ có quyền truy cập vào tất cả dữ liệu và chức năng mà tài khoản bị xâm phạm có. Nếu họ có thể xâm phạm tài khoản có đặc quyền cao, chẳng hạn như quản trị viên hệ thống, họ có thể có toàn quyền kiểm soát toàn bộ ứng dụng và có khả năng giành quyền truy cập vào cơ sở hạ tầng nội bộ.

Ngay cả việc xâm phạm tài khoản có đặc quyền thấp vẫn có thể cấp cho kẻ tấn công quyền truy cập vào dữ liệu mà chúng không nên có, chẳng hạn như thông tin kinh doanh nhạy cảm về mặt thương mại. Ngay cả khi tài khoản không có quyền truy cập vào bất kỳ dữ liệu nhạy cảm nào, nó vẫn có thể cho phép kẻ tấn công truy cập vào các trang bổ sung, tạo cơ sở tấn công sâu hơn. Thông thường, các cuộc tấn công có mức độ nghiêm trọng cao nhất định sẽ không thể xảy ra từ các trang có thể truy cập công khai, nhưng chúng có thể xảy ra từ một trang nội bộ.

Các lỗ hổng trong cơ chế xác thực( Authentication mechanism)

Một lỗ hổng xác thực hệ thống của website luôn luôn gồm có một vài cơ chế rõ ràng nơi mà lỗ hổng có thể xuất hiện. Một vài lỗ hổng có thể áp dụng rộng rãi trên tất cả mọi bối cảnh trong khi những lỗ hổng khác cụ thể hơn đối với chức năng được cung cấp

Lỗ hổng trong login dựa vào password

Trong phần này, chúng ta sẽ xem xét kỹ hơn một số lỗ hổng phổ biến nhất xảy ra trong cơ chế đăng nhập dựa trên mật khẩu. Chúng tôi cũng sẽ đề xuất những cách mà chúng có thể được khai thác. Thậm chí còn có một số phòng thí nghiệm tương tác để bạn có thể tự mình thử và khai thác các lỗ hổng này.Đối với các trang web áp dụng quy trình đăng nhập dựa trên mật khẩu, người dùng có thể tự đăng ký tài khoản hoặc họ được quản trị viên chỉ định tài khoản. Tài khoản này được liên kết với một tên người dùng duy nhất và một mật khẩu bí mật mà người dùng nhập vào biểu mẫu đăng nhập để xác thực chính họ.Trong trường hợp này, việc họ biết mật khẩu bí mật được coi là bằng chứng đầy đủ về danh tính của người dùng. Do đó, tính bảo mật của trang web sẽ bị xâm phạm nếu kẻ tấn công có thể lấy hoặc đoán thông tin đăng nhập của người dùng khác.Điều này có thể đạt được theo nhiều cách khác nhau, như chúng ta sẽ khám phá bên dưới.

Tấn công Brute-force

Một cuộc tấn công Brute-Force là khi kẻ tấn công sử dụng một hệ thống thử và lỗi để đoán thông tin hợp lệ của người dùng. Các cuộc tấn công này thường được tự động hóa sử dụng một wordlists chứa username và password. Tự động quá trình này, đặc biệt sử dụng tool, nó cho phép kẻ tấn công có thể thực hiện nhiều lần đăng nhập ở một tốc độ nhanh hơn

Brut-forcing không phải khi nào cũng chỉ radom đoán username hay password. Mà còn sử dụng logic cơ bản hoặc kiến thức công khai. những kẻ tấn công có thể tinh chỉnh các cuộc tấn công bạo lực để đưa ra các phỏng đoán có học thức hơn nhiều. Điều này làm tăng đáng kể hiệu quả của các cuộc tấn công như vậy. Các trang web dựa vào đăng nhập dựa trên mật khẩu làm phương pháp xác thực người dùng duy nhất của họ có thể rất dễ bị tấn công nếu họ không thực hiện đầy đủ biện pháp bảo vệ bạo lực.

Brute-forcing Usernames

Usernames đặc biệt dễ để đoán nếu chúng phù hợp với những mẫu nhận biết như tài khoản email, tên youtube, tên facebook....

Brute-forcing passwords

Passwords có thể bị brute-force tương tự nhưng độ khó sẽ dựa trên độ dài của password và các ký tự của pass.

Nhiều trang web áp dụng một số hình thức chính sách mật khẩu, buộc người dùng phải tạo mật khẩu có độ phức tạp cao, ít nhất về mặt lý thuyết, khó bị bẻ khóa chỉ bằng cách sử dụng brute-force. Điều này thường liên quan đến việc thực thi mật khẩu với:

• Số lượng ký tự tối thiểu

• Hỗn hợp chữ thường và chữ hoa

• Ít nhất một ký tự đặc biệt

Trích xuất Username

Trích xuất username là khi kẻ tấn công có thể quan sát những thay đổi trong hành vi của website để xác định tên người dùng có hợp lệ hay không.

Trích xuất username thường xảy ra trên trang đăng nhập, ví dụ: khi bạn nhập tên người dùng hợp lệ nhưng mật khẩu không chính xác hoặc trên các biểu mẫu đăng ký khi bạn nhập tên người dùng đã được sử dụng. Điều này làm giảm đáng kể thời gian và nỗ lực cần thiết để bắt buộc đăng nhập vì kẻ tấn công có thể nhanh chóng tạo ra một danh sách rút gọn các tên người dùng hợp lệ.

Trong khi cố gắng cưỡng bức một trang đăng nhập, bạn nên đặc biệt chú ý đến bất kỳ sự khác biệt nào trong:

• Status codes : Trong một cuộc tấn công brute-force, mã trạng thái HTTP trả về có thể giống nhau đối với phần lớn các phỏng đoán vì hầu hết chúng đều sai. Nếu một phỏng đoán trả về một mã trạng thái khác, thì đây là một dấu hiệu mạnh mẽ cho thấy tên người dùng là chính xác. Cách tốt nhất là các trang web luôn trả về cùng một mã trạng thái bất kể kết quả như thế nào, nhưng thực tế này không phải lúc nào cũng được tuân thủ.

• Error mesages: Đôi khi thông báo lỗi trả về khác nhau tùy thuộc vào việc cả tên người dùng và mật khẩu đều không chính xác hay chỉ có mật khẩu không chính xác. Cách tốt nhất là các trang web nên sử dụng các thông báo giống nhau, chung chung trong cả hai trường hợp, nhưng đôi khi các lỗi đánh máy nhỏ cũng xuất hiện. Chỉ cần một ký tự không đúng vị trí sẽ khiến hai thông báo trở nên khác biệt, ngay cả trong trường hợp ký tự không hiển thị trên trang được hiển thị.

• Respones times : Nếu hầu hết các yêu cầu được xử lý với thời gian phản hồi tương tự, bất kỳ yêu cầu nào khác với điều này cho thấy có điều gì đó khác đang xảy ra ở hậu trường. Đây là một dấu hiệu khác cho thấy tên người dùng được đoán có thể đúng. Ví dụ: một trang web chỉ có thể kiểm tra xem mật khẩu có đúng hay không nếu tên người dùng hợp lệ. Bước bổ sung này có thể làm tăng một chút thời gian phản hồi. Điều này có thể là tinh tế, nhưng kẻ tấn công có thể làm cho sự chậm trễ này rõ ràng hơn bằng cách nhập một mật khẩu quá dài mà trang web cần nhiều thời gian hơn để xử lý.

Địa chỉ IP user

• Lab: Username enumeration via different responses
• Lab: Username enumeration via subtly different responses
• Lab: Username enumeration via response timing

Flawed brute-force protection

Có khả năng cao là brute-force sẽ liên quan đến nhiều lần đoán không thành công trước khi kẻ tấn công xâm nhập tài khoản thành công. Về mặt logic, bảo vệ brute-force xoay quanh việc cố gắng làm cho nó trở nên khó khăn nhất có thể để tự động hóa quá trình và làm chậm tốc độ mà kẻ tấn công có thể cố gắng đăng nhập. Hai cách phổ biến nhất để ngăn chặn các cuộc tấn công brute-force là:

• Khóa tài khoản mà người dùng từ xa đang cố gắng truy cập nếu họ thực hiện quá nhiều lần đăng nhập không thành công

• Chặn địa chỉ IP của người dùng từ xa nếu họ thực hiện quá nhiều lần đăng nhập liên tiếp

Cả hai cách tiếp cận đều cung cấp các mức độ bảo vệ khác nhau, nhưng không phải là bất khả xâm phạm, đặc biệt nếu được thực hiện bằng cách sử dụng logic sai sót.

Ví dụ: đôi khi bạn có thể thấy rằng IP của mình bị chặn nếu bạn không đăng nhập quá nhiều lần. Trong một số triển khai, bộ đếm số lần thử không thành công sẽ đặt lại nếu chủ sở hữu IP đăng nhập thành công. Điều này có nghĩa là kẻ tấn công sẽ chỉ cần đăng nhập vào tài khoản của họ sau vài lần cố gắng để ngăn không cho đạt đến giới hạn này.

Trong trường hợp này, chỉ cần bao gồm thông tin đăng nhập của riêng bạn vào các khoảng thời gian đều đặn trong suốt danh sách từ là đủ để khiến biện pháp bảo vệ này hầu như vô dụng.

Note: Ở đây có nghĩa nếu khi bạn đăng nhập tài khoản nạn nhân sai thì bạn phải đăng nhập tải khoản của bạn thì lúc đó cơ chế bảo vệ khỏi tấn công brute-force bởi khóa tài khoản nạn nhân hoặc chặn IP sẽ bị broken. Và nên nhớ rằng nếu dùng burp Suite thì chỉnh Resource Pool là request tối đa là 1

• Lab: Broken brute-force protection, IP block

Account locking

Một cách mà các trang web cố gắng ngăn chặn hành vi brute-force là khóa tài khoản nếu phát hiện ra một số hành động đáng ngờ nhất định, thường là một số lần đăng nhập không thành công. Cũng giống như các lỗi đăng nhập thông thường, phản hồi từ máy chủ cho biết tài khoản bị khóa cũng có thể giúp kẻ tấn công liệt kê tên người dùng.

• Lab: Username enumeration via account lock

Ở đây chúng ta sẽ phải tìm thông tin người dùng chính xác trong wordlist bằng cách xem sự phản hồi của tài khoản khác với các tài khoản còn lại, trong burp suite thì trong payload của pass là test$$ ....................................sau đó check pass cũng xem sự phản hồi của web.

User rate limiting(Limit user)

Một cách khác mà các trang web cố gắng ngăn chặn các cuộc tấn công brute-force là thông qua giới hạn tỷ lệ người dùng. Trong trường hợp này, việc thực hiện quá nhiều yêu cầu đăng nhập trong một khoảng thời gian ngắn khiến địa chỉ IP của bạn bị chặn. Thông thường, chỉ có thể bỏ chặn IP bằng một trong các cách sau:

• Tự động sau một khoảng thời gian nhất định đã trôi qua

• Do quản trị viên thực hiện theo cách thủ công

• Do người dùng thủ công sau khi hoàn thành CAPTCHA thành công

Giới hạn tỷ lệ người dùng đôi khi được ưu tiên để khóa tài khoản do ít bị liệt kê tên người dùng và các cuộc tấn công từ chối dịch vụ. Tuy nhiên, nó vẫn không hoàn toàn an toàn. Như chúng ta đã thấy một ví dụ về một phòng thí nghiệm trước đó, có một số cách kẻ tấn công có thể thao túng IP rõ ràng của chúng để vượt qua khối.

Vì giới hạn dựa trên tỷ lệ yêu cầu HTTP được gửi từ địa chỉ IP của người dùng, đôi khi cũng có thể vượt qua lớp bảo vệ này nếu bạn có thể tìm ra cách đoán nhiều mật khẩu với một yêu cầu duy nhất.

• Broken brute-force protection, multiple credentials per request

Thường nếu web gửi thông tin đăng nhập theo dạng JSON thì thì khi đó chúng ta nếu biết username thì chèn một lúc nhiều password vào đó, khi web trả về status 302 thì lấy cookie của nó thay cho cookie trang của mình rồi reload là oke.

HTTP basic authentication

Mặc dù khá cũ, nhưng tính đơn giản và dễ triển khai tương đối của nó có nghĩa là đôi khi bạn có thể thấy xác thực cơ bản HTTP được sử dụng. Trong xác thực cơ bản HTTP, máy khách nhận được token authentication từ máy chủ, token này được xây dựng bằng cách ghép tên người dùng và mật khẩu và mã hóa nó trong Base64. Mã thông báo này được lưu trữ và quản lý bởi trình duyệt, trình duyệt này sẽ tự động thêm nó vào Authorization tiêu đề của mọi yêu cầu tiếp theo như sau:

Authorization: Basic base64(username:password)

Ví dụ:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Vì một số lý do, đây thường không được coi là một phương pháp xác thực an toàn. Thứ nhất, nó liên quan đến việc liên tục gửi thông tin đăng nhập của người dùng với mọi yêu cầu. Trừ khi trang web cũng triển khai HSTS, thông tin đăng nhập của người dùng có thể bị bắt trong một cuộc tấn công man-in-the-middle.

Ngoài ra, việc triển khai xác thực cơ bản HTTP thường không hỗ trợ bảo vệ brute-force. Vì token chỉ bao gồm các giá trị tĩnh, điều này có thể khiến nó dễ bị brute-force.

Xác thực cơ bản HTTP cũng đặc biệt dễ bị tấn công bởi các khai thác liên quan đến session, đặc biệt là CSRF , mà nó không tự bảo vệ.

Lỗ hổng trong xác thực đa yếu tố(multi-factor)

Nhiều trang web chỉ dựa vào xác thực một yếu tố bằng cách sử dụng mật khẩu để xác thực người dùng. Tuy nhiên, một số yêu cầu người dùng chứng minh danh tính của họ bằng cách sử dụng nhiều yếu tố xác thực.

Việc xác minh các yếu tố sinh trắc học là không thực tế đối với hầu hết các trang web. Tuy nhiên, việc xác thực hai yếu tố (2FA) bắt buộc và tùy chọn (2FA) dựa trên something you know và something you have ngày càng phổ biến . Điều này thường yêu cầu người dùng nhập cả mật khẩu truyền thống và mã xác minh tạm thời từ thiết bị vật lý ngoài băng tần mà họ sở hữu.

Cũng cần lưu ý rằng lợi ích đầy đủ của xác thực đa yếu tố chỉ đạt được bằng cách xác minh nhiều yếu tố khác nhau . Việc xác minh cùng một yếu tố theo hai cách khác nhau không phải là xác thực hai yếu tố. 2FA dựa trên email là một trong những ví dụ như vậy. Mặc dù người dùng phải cung cấp mật khẩu và mã xác minh, việc truy cập mã chỉ dựa vào việc họ biết thông tin đăng nhập cho tài khoản email của họ. Do đó, yếu tố xác thực tri thức chỉ đơn giản là được xác minh hai lần.

Token xác thực 2 yếu tố

Mã xác minh thường được người dùng đọc từ một thiết bị vật lý nào đó. Nhiều trang web bảo mật cao hiện cung cấp cho người dùng một thiết bị chuyên dụng cho mục đích này, chẳng hạn như mã thông báo RSA hoặc thiết bị bàn phím mà bạn có thể sử dụng để truy cập ngân hàng trực tuyến hoặc máy tính xách tay làm việc của mình. Ngoài mục đích được xây dựng để bảo mật, các thiết bị chuyên dụng này còn có lợi thế là tạo mã xác minh trực tiếp. Các trang web cũng thường sử dụng một ứng dụng di động chuyên dụng, chẳng hạn như Google Authenticator, vì lý do tương tự.

Mặt khác, một số trang web gửi mã xác minh đến điện thoại di động của người dùng dưới dạng tin nhắn văn bản. Mặc dù về mặt kỹ thuật, điều này vẫn đang xác minh yếu tố "something you have", nhưng nó vẫn dễ bị lạm dụng. Thứ nhất, mã đang được truyền qua SMS chứ không phải do chính thiết bị tạo ra. Điều này tạo ra khả năng mã bị chặn. Ngoài ra còn có nguy cơ tráo SIM, theo đó kẻ tấn công lừa đảo lấy được thẻ SIM có số điện thoại của nạn nhân. Sau đó, kẻ tấn công sẽ nhận được tất cả các tin nhắn SMS được gửi đến nạn nhân, bao gồm cả tin nhắn chứa mã xác minh của họ.

Bypass xác thực hai yếu tố

Đôi khi, việc triển khai xác thực hai yếu tố còn thiếu sót đến mức có thể bị bypass hoàn toàn. Nếu lần đầu tiên người dùng được nhắc nhập mật khẩu, sau đó được nhắc nhập mã xác minh trên một trang riêng biệt, thì người dùng thực sự ở trạng thái "logged in" trước khi họ nhập mã xác minh. Trong trường hợp này, bạn nên thử nghiệm để xem liệu bạn có thể trực tiếp chuyển đến các trang "logged-in only" sau khi hoàn thành bước xác thực đầu tiên hay không. Đôi khi, bạn sẽ thấy rằng một trang web không thực sự kiểm tra xem bạn đã hoàn thành bước thứ hai hay chưa trước khi tải trang.

• Lab: 2FA simple bypass

Thường thì bạn có thể chuyển tới trang web đã login của bạn luôn mà không cần xác thực(redirected)

Flawed two-factor verification logic

Đôi khi logic sai sót trong xác thực hai yếu tố có nghĩa là sau khi người dùng đã hoàn thành bước đăng nhập ban đầu, trang web không xác minh đầy đủ rằng chính người dùng đó đang hoàn thành bước thứ hai.

Ví dụ: người dùng đăng nhập bằng thông tin đăng nhập bình thường của họ trong bước đầu tiên như sau:

POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwerty

Sau đó, họ được gán một cookie liên quan đến tài khoản của họ, trước khi được chuyển sang bước thứ hai của quá trình đăng nhập:

HTTP/1.1 200 OK
Set-Cookie: account=carlos

GET /login-steps/second HTTP/1.1
Cookie: account=carlos

Khi gửi mã xác minh, yêu cầu sử dụng cookie này để xác định tài khoản mà người dùng đang cố gắng truy cập:

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456

Trong trường hợp này, kẻ tấn công có thể đăng nhập bằng thông tin đăng nhập của chính họ nhưng sau đó thay đổi giá trị của account cookie thành bất kỳ tên người dùng tùy ý nào khi gửi mã xác minh.

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456

Điều này cực kỳ nguy hiểm nếu sau đó kẻ tấn công có thể cưỡng bức mã xác minh vì nó sẽ cho phép chúng đăng nhập vào tài khoản của người dùng tùy ý hoàn toàn dựa trên tên người dùng của họ. Họ thậm chí sẽ không bao giờ cần biết mật khẩu của người dùng.

• Lab: 2FA broken logic

Nếu kẻ tấn công biết định dạng mã code thì mã code đó có thể bị brute-force, trong trường hợp cookie có liên quan tới tên người dùng....

Brute-forcing mã xác thực 2FA

Với những mật khẩu, websites cần thực hiện các bước để bảo vệ mã xác thực 2FA trước brute-force. Điều này đặc biệt quan trọng vì mã thường là một số có 4 hoặc 6 chữ số đơn giản. Nếu không có biện pháp bảo vệ brute-force thích hợp, việc bẻ khóa mã như vậy là điều tầm thường.

Một số trang web cố gắng ngăn chặn điều này bằng cách tự động đăng xuất người dùng nếu họ nhập một số lượng mã xác minh không chính xác. Điều này không hiệu quả trong thực tế vì kẻ tấn công nâng cao thậm chí có thể tự động hóa quy trình nhiều bước này bằng cách tạo macro cho Burp Intruder. Phần mở rộng Turbo Intruder cũng có thể được sử dụng cho mục đích này.

• Lab: 2FA bypass using a brute-force attack

Các lỗ hổng trong các cơ chế xác thực khác

Ngoài chức năng đăng nhập cơ bản, hầu hết các trang web đều cung cấp chức năng bổ sung để cho phép người dùng quản lý tài khoản của họ. Ví dụ, người dùng thường có thể thay đổi mật khẩu hoặc đặt lại mật khẩu khi họ quên. Các cơ chế này cũng có thể giới thiệu các lỗ hổng có thể bị kẻ tấn công khai thác.

Các trang web thường cẩn thận để tránh các lỗ hổng nổi tiếng trong các trang đăng nhập của họ. Nhưng có thể dễ dàng bỏ qua thực tế rằng bạn cần thực hiện các bước tương tự để đảm bảo rằng chức năng liên quan cũng mạnh mẽ như nhau. Điều này đặc biệt quan trọng trong trường hợp kẻ tấn công có thể tạo tài khoản của riêng họ và do đó, có thể dễ dàng truy cập để nghiên cứu các trang bổ sung này.

Keeping users logged in

Một tính năng phổ biến là tùy chọn để duy trì trạng thái đăng nhập ngay cả sau khi đóng phiên trình duyệt. Đây thường là một hộp kiểm đơn giản có nhãn như "Remember me" hoặc "Keep me logged in"

Chức năng này thường được triển khai bằng cách tạo một loại mã thông báo "remember me", sau đó được lưu trữ trong một cookie liên tục. Vì sở hữu cookie này một cách hiệu quả cho phép bạn bỏ qua toàn bộ quy trình đăng nhập, nên cách tốt nhất là không thể đoán được cookie này. Tuy nhiên, một số trang web tạo cookie này dựa trên sự ghép nối có thể dự đoán được của các giá trị tĩnh, chẳng hạn như username and timestamp. Một số thậm chí sử dụng mật khẩu như một phần của cookie. Cách tiếp cận này đặc biệt nguy hiểm nếu kẻ tấn công có thể tạo tài khoản của riêng họ vì họ có thể nghiên cứu cookie của chính họ và có khả năng suy ra cách nó được tạo ra. Khi họ tìm ra công thức, họ có thể cố gắng brute-force cookie của người dùng khác để có quyền truy cập vào tài khoản của họ.

Một số trang web cho rằng nếu cookie được mã hóa theo một cách nào đó, nó sẽ không thể đoán được ngay cả khi nó sử dụng các giá trị tĩnh. Mặc dù điều này có thể đúng nếu được thực hiện đúng cách, nhưng việc "encrypting" cookie một cách ngây thơ bằng cách sử dụng mã hóa hai chiều đơn giản như Base64 không cung cấp bất kỳ biện pháp bảo vệ nào. Ngay cả khi sử dụng mã hóa thích hợp với hàm băm một chiều cũng không hoàn toàn chống được đạn. Nếu kẻ tấn công có thể dễ dàng xác định thuật toán băm và không có muối nào được sử dụng, chúng có thể có khả năng brute-force cookie bằng cách đơn giản hash wordlists. Phương pháp này có thể được sử dụng để bypass giới hạn số lần đăng nhập nếu một giới hạn tương tự không được áp dụng cho các lần đoán cookie.

• Lab: Brute-forcing a stay-logged-in cookie

Để làm lab này thì các bạn nên đọc rõ về các phần này trong Burp

Ngay cả khi kẻ tấn công không thể tạo tài khoản của riêng họ, họ vẫn có thể khai thác lỗ hổng này. Sử dụng các kỹ thuật thông thường, chẳng hạn như XSS , kẻ tấn công có thể đánh cắp cookie "remember me" của người dùng khác và suy ra cách cookie được xây dựng từ đó. Nếu trang web được xây dựng bằng khung mã nguồn mở, thì các chi tiết chính của việc xây dựng cookie thậm chí có thể được ghi lại công khai.

Trong một số trường hợp hiếm hoi, có thể lấy được mật khẩu thực của người dùng dưới dạng văn bản rõ ràng từ cookie, ngay cả khi nó đã được băm. Phiên bản băm của danh sách mật khẩu nổi tiếng có sẵn trực tuyến, vì vậy nếu mật khẩu của người dùng xuất hiện trong một trong những danh sách này, việc giải mã hàm băm đôi khi có thể đơn giản như chỉ dán mã băm vào công cụ tìm kiếm. Điều này chứng tỏ tầm quan trọng của muối trong việc mã hóa hiệu quả.

• Lab: Offline password cracking

Resetting user passwords

Trong thực tế, có một số người dùng sẽ quên mật khẩu của họ, vì vậy thông thường sẽ có cách để họ đặt lại mật khẩu. Vì xác thực dựa trên mật khẩu thông thường rõ ràng là không thể trong trường hợp này, các trang web phải dựa vào các phương pháp thay thế để đảm bảo rằng người dùng thực đang đặt lại mật khẩu của chính họ. Vì lý do này, chức năng đặt lại mật khẩu vốn đã rất nguy hiểm và cần được triển khai một cách an toàn.

Sending passwords by email

Không nên nói rằng việc gửi cho người dùng mật khẩu hiện tại của họ sẽ không bao giờ có thể thực hiện được nếu một trang web xử lý mật khẩu một cách an toàn ngay từ đầu. Thay vào đó, một số trang web tạo mật khẩu mới và gửi mật khẩu này cho người dùng qua email.

Nói chung, việc gửi mật khẩu liên tục qua các kênh không an toàn là điều nên tránh. Trong trường hợp này, bảo mật dựa vào mật khẩu được tạo sẽ hết hạn sau một thời gian rất ngắn hoặc người dùng thay đổi lại mật khẩu của họ ngay lập tức. Nếu không, cách tiếp cận này rất dễ bị tấn công bởi kẻ trung gian.

Email thường không được coi là an toàn vì hộp thư đến đều liên tục và không thực sự được thiết kế để lưu trữ an toàn thông tin bí mật. Nhiều người dùng cũng tự động đồng bộ hóa hộp thư đến của họ giữa nhiều thiết bị trên các kênh không an toàn.

Resetting passwords using a URL

Một phương pháp đặt lại mật khẩu mạnh mẽ hơn là gửi một URL duy nhất cho người dùng để đưa họ đến trang đặt lại mật khẩu. Các triển khai kém an toàn hơn của phương pháp này sử dụng URL có thông số dễ đoán để xác định tài khoản nào đang được đặt lại.

Ví dụ:

http://vulnerable-website.com/reset-password?user=victim-user

Ví dụ kẻ tấn công có thể thay đổi tham số user để tham chiếu đến bất kỳ tên người dùng nào mà chúng đã xác định. Sau đó, họ sẽ được đưa thẳng đến một trang mà họ có thể đặt mật khẩu mới cho người dùng tùy ý này.

Cách triển khai tốt hơn của quá trình này là tạo một high-entropy, hard-to-guess token và tạo URL đặt lại dựa trên đó. Trong trường hợp tốt nhất, URL này sẽ không cung cấp gợi ý về mật khẩu của người dùng nào đang được đặt lại.

http://vulnerable-website.com/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8

Khi người dùng truy cập vào URL này, hệ thống sẽ kiểm tra xem mã thông báo này có tồn tại trên back-end hay không và nếu có, mật khẩu của người dùng nào nó được yêu cầu đặt lại. Mã thông báo này sẽ hết hạn sau một khoảng thời gian ngắn và bị hủy ngay sau khi mật khẩu được đặt lại.

Tuy nhiên, một số trang web cũng không thể xác thực lại mã thông báo khi biểu mẫu đặt lại được gửi. Trong trường hợp này, kẻ tấn công có thể chỉ cần truy cập biểu mẫu đặt lại từ tài khoản của chính họ, xóa mã thông báo và tận dụng trang này để đặt lại mật khẩu của người dùng tùy ý.

Ở đây có thể nói trang web đang bị lỗi ở xác thực mã thông báo. Nếu bị lỗi thì khi đó không cần mã thông báo kẻ tấn công có thể đặt lại mật khẩu trong cùng một session đó.

• Lab:Password reset broken logic

Nếu URL trong email đặt lại được tạo động, thì URL này cũng có thể dễ bị nhiễm độc đặt lại mật khẩu. Trong trường hợp này, kẻ tấn công có thể ăn cắp mã thông báo của người dùng khác và sử dụng nó để thay đổi mật khẩu của họ.

• Lab: Password reset poisoning via middleware

Thường những lab như này thì sẽ sử dụng X-Forwarded-Host các bạn có thể xem ở trên cùng bài viết, chỉ cần dùng Burp suite bắt ở lúc gửi link về email thì khi đó mình chèn host mình vào khi đó nó gửi token về domain của mình hoặc sau đó mình thay token vào sau link. Hoặc nó vẫn sẽ gửi link request pass về mail nạn nhân nhưng mà nếu nạn nhân click vào link thì token sẽ gửi về domain mà mình kiểm soát.

Changing user passwords

Thông thường, thay đổi mật khẩu liên quan tới nhập mật khẩu hiện tại của bạn vvaf nhập khẩu mới hai lần. Các trang này về cơ bản dựa trên cùng một quy trình để kiểm tra xem tên người dùng và mật khẩu hiện tại có khớp như một trang đăng nhập bình thường hay không. Do đó, các trang này có thể dễ bị tấn công bởi các kỹ thuật tương tự.

Chức năng thay đổi mật khẩu có thể đặc biệt nguy hiểm nếu nó cho phép kẻ tấn công truy cập trực tiếp mà không cần đăng nhập với tư cách là người dùng nạn nhân. Ví dụ: nếu tên người dùng được cung cấp trong trường ẩn, kẻ tấn công có thể chỉnh sửa giá trị này trong yêu cầu để nhắm mục tiêu người dùng tùy ý. Điều này có thể bị lợi dụng để liệt kê tên người dùng và mật khẩu brute-force.

• Lab: Password brute-force via password change

Các lỗ hổng trong cơ chế xác thực của bên thứ ba

Cái này mình viết hẳn ra một bài mới: OAuth 2.0 authentication vulnerabilities

Ngăn chặn các cuộc tấn công vào cơ chế xác thực

1. Triển khai hệ thống chống brute-force đáng tin cậy: Có thể ngăn chặn các cuộc tấn công bạo lực bằng cách thực thi khóa tài khoản, giới hạn tốc độ, giám sát dựa trên IP, tường lửa ứng dụng và CAPTCHA.

2. Thực thi chính sách mật khẩu an toàn: Thực hiện việc này bằng cách tạo trình kiểm tra mật khẩu cho người dùng biết mật khẩu của họ mạnh đến mức nào trong thời gian thực. Bạn cũng có thể triển khai xác thực passwordless authentication bằng cách sử dụng các tiêu chuẩn như FIDO2 để giảm thiểu rủi ro và căng thẳng khi quản lý mật khẩu.
3. Áp dụng bảo mật truyền tải nghiêm ngặt HTTP (HSTS): Điều này buộc các phiên web sử dụng mã hóa TLS, ngăn thông tin nhạy cảm bị truy cập khi chuyển tiếp.

4. Cân nhắc việc tắt liệt kê tên người dùng: Bằng cách tạo ra cùng một lỗi cho một lần đăng nhập không thành công cho dù tên người dùng hợp lệ hay không hợp lệ, bạn buộc kẻ tấn công phải cưỡng bức không chỉ bộ mật khẩu có thể có mà còn cả bộ tên người dùng có khả năng xảy ra, thay vì dính vào những cái họ biết là hợp lệ.

5. Sửa đổi tiêu đề cookie: Việc sửa đổi tiêu đề cookie bảo vệ chúng khỏi các cuộc tấn công độc hại. Việc sử dụng các thẻ HttpOnly và SameSite khi đặt tiêu đề cookie sẽ ngăn chúng khỏi các cuộc tấn công XSS và CSRF, tương ứng.

6. Kiểm tra kỹ lưỡng mã của bạn khi xác minh: Điều này rất quan trọng để phát hiện bất kỳ lỗ hổng nào trong mã của bạn.

7. Sử dụng câu lệnh được tham số hóa: Bạn có thể ngăn chặn các cuộc tấn công SQL Injection thông qua xác thực đầu vào và các truy vấn được tham số hóa. Chúng an toàn hơn khi tránh đưa trực tiếp đầu vào do người dùng cung cấp trực tiếp vào các câu lệnh SQL.

8. Thực hiện multi-factor authentication thích hợp: Sử dụngmulti-factor authentication an toàn hơn cơ chế dựa trên mật khẩu. Tuy nhiên, bạn cần có mã vững chắc và tạo mã xác minh an toàn để triển khai hiệu quả hình thức xác thực này.

Cảm ơn các bạn đã đọc bài viết của mình. Bài viết này mình vừa học vừa viết ra từ PortSwigger nên có gì sai sót thì mong mn bỏ qua.