NextSec.vn

  Như anh em đã/đang/sẽ nghiên cứu và thi OSCP thì sẽ biệt một chính sách của OSCP là cấm sử dụng các công cụ khai thác tự động. Chính sách này rất đúng vì nó tránh được việc không cần hiểu bản chất mà cứ chạy tool là khai thác thành công - script kiddie. Sau đây là danh sách không chính thức các công cụ được OSCP phê duyệt đã được đăng trong PWK / OSCP Prep Discord Server (https://discord.gg/eG6Nt4x). Lưu ý:  - Ở đây không thống kê danh sách đầy đủ tất cả các công cụ, chỉ là những công cụ được đề xuất bởi những người chơi OSCP khác, tạm coi là "được chấp thuận" cho kỳ thi. - Sẽ có một số công cụ trên đây không được đề khuyến nghị trên Discord. - Theo nguyên tắc chung của OSCP: nếu một công cụ có thể tự động khai thác, nó sẽ bị cấm trong kỳ thi. - Danh sách có thể thay đổi theo thời gian - Update lần cuối: 13/12/2020. Note Taking CherryTree -  https://www.giuspen.com/cherrytree/  (Template:  https://411hall.github.io/assets/files/CTF_template.ctb ) KeepNote -  http://keepnote

  I. Access Control Thực hiện kiểm tra quyền truy cập các tài nguyên trên trang web theo đúng quyền hạn mà user được cấp. Thực hiện phân quyền tối thiểu và đúng vai trò của mỗi người dùng là yếu tố then chốt trong việc thực hiện kiểm tra phân quyền. 1. Chỉ thực hiện phân quyền trên các hệ thống tin cậy, không thực hiện phần quyền ở phía client Hệ thống đáng tin cậy có thể là server do chúng ta quản lý, server của các bên thứ 3 đủ độ tin cậy và an toàn. Tuyệt đối không thực hiện việc phân quyền người dùng ở phía client vì việc này không an toàn và không đảm bảo tính bảo mật cho ứng dụng. 2. Sử dụng một module chuyên biệt để thực hiện kiểm tra phân quyền (single site-wide) Thực hiện kiểm tra phân quyền sử dụng các thư thư viện gọi tới các module phân quyền từ bên ngoài 3. Xử lý các truy cập trái phép về quyền một cách án toàn (fail securely) Tìm hiểu thêm về fail secure tại fail secure . Đây là một cơ chế xử lý phân quyền một cách an toàn, mặc định ban đầu sẽ từ chối tất cả quyền đổi với

Bài viết này mình sẽ đưa ra một số khái niệm cũng như nhưng điểm lưu ý giúp chúng ta có thể phân biệt được Encode, Encryption hay Hash. Bởi trong thực tế mình biết khá nhiều bạn sẽ biết về các khái niệm này, tuy nhiên sẽ không phân biệt cụ thể được chúng mà chỉ ở mức " Ừm, có lẽ chúng dùng để bảo mật 😄". Cũng không hoàn toàn sai, nhưng chúng ta sẽ tìm hiểu cụ thể xem chúng khác nhau như nào nhé. Let's go ! Enconding Đây là một phương pháp được sử dụng khá nhiều trong các hệ thống ngày nay. Bạn đang nghĩ đây là cách chúng ta dùng để bảo mật? Các thông tin nhạy cảm như tên tuổi, địa chỉ hay tài khoản khách hàng có thể lưu an toàn với encoding ? Không phải như vậy nhé! Khoan, hãy nhìn vào bảng trên. Các bạn có thấy quen thuộc không ? Đây chính là bảng mã ASCii mà chúng ta mài mông nghiên cứu trên ghế giảng đường 😄 Khoan hãy nói về encoding. Các bạn có nhơ chúng ta đã từng làm những bài tập vỡ lòng dạng chuyển đổi 1 đoạn text thành mã bit và ngược lại hay không. Ví dụ: A -&

I. Authentication and Password Management Các khuyến nghị trong mục Authentication and Password Management giúp đảm bảo an toàn cho việc xác thực người dùng cũng như bảo vệ thông tin đăng nhập một cách an toàn, ngăn chặn các cuộc tấn công phá vỡ cơ chế xác thực của hệ thống. 1. Yêu cầu xác thực cho tất cả các trang và tài nguyên, ngoại trừ những trang và tài nguyên đặc biệt dành cho cộng đồng. Đối với các tài nguyên quan trọng không được phép truy cập public thì chúng ta cần thực hiện việc xác thực (authenticate) người dùng ở mọi trang hoặc mọi tài nguyên. Những tài nguyên public không cần thực hiện có thể là cái file: css, js, tài liệu hoặc tài nguyên public. 2. Mọi cơ chế xác thực cần thực hiện trên một hệ thống tin cậy. Hệ thống đáng tin cậy có thể là server do chúng ta quản lý, server của các bên thứ 3 đủ độ tin cậy và an toàn. Tuyệt đối không thực hiện việc xác thực người dùng ở phía client vì việc này không an toàn và không đảm bảo tính bảo mật cho ứng dụng. 3. Thiết lập và sử dụ

Phần lớn các vấn đề bảo mật đều liên quan đến các lỗi lập trình! Mặc dù không một lập trình viên nào khi viết ứng dụng lại mong muốn ứng dụng của mình sẽ có lỗi bảo mật, nhưng trên thực tế, do tính phức tạp của các hệ thống kỹ thuật, do tập trung quan tâm đến chức năng hấp dẫn của ứng dụng, đến tiến độ… việc đảm bảo ứng dụng không có lỗi bảo mật là cực kỳ khó khăn, ngay cả với những lập trình viên cao cấp. Nói chung, việc xây dựng phần mềm an toàn sẽ ít tốn kém hơn nhiều so với việc sửa chữa các vấn đề bảo mật sau khi phần mềm đã hoàn thành, chưa kể các chi phí có thể liên quan đến vi phạm bảo mật. Chuỗi bài viết này được tham khảo từ:  Full document:  OWASP Secure Coding Practices-Quick Reference Guide Slide for presentation:  PowerPoint Presentation (dga.or.th) I. Input Validation Yêu cầu này liên quan đến việc kiểm tra dữ liệu đầu vào, các lập trình viên cần đảm bảo kiểm tra toàn bộ dữ liệu đầu vào từ phía người dùng và xử lý hay kiểm tra chúng ở phía server (không xử lý ở phía clie

Web là một trong những mảng dễ tiếp cận khi chơi CTF. Vậy bắt đầu CTF mảng Web như thế nào? Giờ đặt một website trước mặt mình thì không thể cứ thế mà làm. Làm gì? Tìm flag - một chuỗi bí mật do người ra đề giấu ở đâu đó quanh cái web. Muốn tìm được nó trước hết phải xem đề bài gợi ý cái gì, cho cái gì, trong web có gì, làm sao để khai thác mấy cái đó. Từ đây lại có một vấn đề: Phải hiểu về web trước đã. Nói thêm một chút là ở bài viết này mình sẽ không đi sâu vào chi tiêt, mình chỉ dừng lại ở việc đặt ra các vấn đề quan trọng mà các bạn cần tìm hiểu. Web hoạt động thế nào? Chúng ta sẽ cần nắm kiến thức về web qua những vấn đề như thế này:   - Cách hoạt động của web từ phía client cho đến phía server sẽ có những gì?   - Client gửi request cho server và nhận lại response như thế nào? Qua đâu? (HTTP, HTTP Header, HTTP Methods)   - Cách client và server lưu trữ thông tin của nhau (qua cơ sở dữ liệu, cookie, session, …).   - Các ngôn ngữ cấu thành 1 trang web hoặc thường được dùng khi