Chuyển đến nội dung chính

Bài đăng

Chuyện nghề

"- Có nơi than, 1 giờ anh đòi đến mấy trăm đô, bằng lương người ta làm cả tháng.   Có nơi không tin, lỡ anh làm có 1 giờ mà tính tiền 10 giờ?  Tôi nói:  " uy tín của tôi đáng giá hơn 10 giờ" . Nếu tôi ẩu, chỉ làm 1 giờ, sau này người ta phát hiện ra những vấn đề đơn giản trong phần tôi đã coi, uy tín chắc chỉ còn nước thảy cho chó gặm. " Từ hồi đi làm đến giờ, tôi gặp nhiều tình huống không biết nên trả lời thế nào cho đúng, hôm nay ghi lại đây để mai mốt ai có gặp tham khảo. Khi được liên hệ, tôi thấy đa phần các đơn vị làm xong rồi mới nghĩ đến chuyện kiểm thử, thậm chí là bị hack rồi mới nghĩ tới. Việc kiểm thử nên được triển khai ngay từ khi Phân tích thiết kế hệ thống . Các luồng đi của dữ liệu khi phác thảo ý tưởng ở trên giấy cũng cần kiểm tra tính an toàn, nếu để đến khi đã ra sản phẩm rồi thì đi sửa lại mất nhiều thời gian, công sức hơn nhiều, thậm trí sửa lại sinh ra lỗi mới. Thằng em tôi làm graphic designer hay "được nhờ" vẽ hộ logo hay vẽ cái
Các bài đăng gần đây

HttpOnly Flag và Secure Flag của chiếc Cookie để làm gì?

Cookies rất hữu ích nhưng cũng tồn tại không ít rủi ro. Bài viết sau đây giúp tìm hiểu rõ thêm về 2 thuộc tính giúp bảo vệ Cookies là Httponly flag   và Secure flag.   Nếu anh em mò vào được bài này thì chắc cũng biết về Cookie rồi, nhưng còn hiểu lơ mơ    thì click vào đây trước nhé -  Cookie . Chuyện kể rằng, ngày xửa ngày xưa, có một "nghệ sĩ" nọ do không sao kê tiền từ thiện nên đã bị hacker tấn công chiếm rất nhiều tài khoản do bị mất cookie.  1. Tại sao lại mất?   Nguyên nhân "nghệ sĩ" bị mất thông tin cá nhân là do quá chủ quan khi click đọc email do rất nhiều "fan" gửi cho, trong những email đó có gắn đường link chứa mã độc đánh cắp cookie của 1 trang web nào đó.  Do cookies phản hồi từ server mà các đường link đó dẫn tới không được bảo vệ     nên đã bị đối tượng xấu lấy mất cookies chứa xác thực đăng nhập -> dẫn tới mất thông tin. Về mặt bản chất, cũng có thể hiểu đây như là một cuộc tấn công XSS , đối tượng gửi email sẽ execute một đoạn scri

[Relax] Cuốn sách "300 bài code thiếu nhi" phiên bản "Có thật"

Lưu ý: sách ở cuối bài nhé! Trong giới IT từ lâu đã lưu truyền giai thoại về cuốn sách đổi đời có tên "300 bài code thiếu nhi". Theo đó, nhiều người thuộc tầng lớp khác nhau đã thành đạt, lương ngàn đô nhờ vô tình nhặt được và học theo những bài code trong cuốn sách này. Những câu chuyện đổi đời nhờ cuốn sách "300 bài code thiếu nhi" 1. Bà hàng xóm nhà mình đây, trước đi buôn đồng nát, tình cờ có thằng sinh viên khoa CNTT nó bán đống sách cũ. Thế nào mà bà ấy mua "300 bài code thiếu nhi" cầm về đọc. Rồi sáng đi mua đồng nát, tối về đọc sách, cuối tuần ra quán net thực hành. Sáu tháng sau bà ấy khăn gói lên Hà Nội đi phỏng vấn, cũng nhờ code trên giấy nhiều mà mấy bài "white board" bà ấy làm ngon ơ. Cũng 5 năm rồi, giờ đang làm lead ở một công ty khá lớn. Đúng là cái nghề này mang lại cơ hội đổi đời cho nhiều người. 2. Quê tôi miền biển, có gia đình cạnh nhà làm nghề chài lưới. Bữa đi kéo lưới, anh chồng thấy nặng nặng tưởng được mẻ cá to, ai ngờ

Security architecture và con đường sự nghiệp

Kiến trúc bảo mật (security architecture) thực sự là gì? Các thành phần và lợi ích của security architecture? Kiến trúc sư bảo mật  (security architect) làm gì và cần có những kỹ năng gì để làm tốt vai trò của mình? Cơ hội nghề nghiệp của các kiến trúc sư bảo mật ra sao? Họ cần những chứng chỉ gì? Lương bổng ra sao? Chúng ta hãy cùng tìm hiểu trong bài viết này. Kiến trúc bảo mật là gì? Kiến trúc bảo mật là một khuôn khổ (framework) xác định cấu trúc tổ chức, tiêu chuẩn, chính sách và hành vi chức năng của mạng máy tính, bao gồm cả tính năng bảo mật và mạng. Kiến trúc bảo mật cũng là cách thức mà các thành phần khác nhau của hệ thống mạng hoặc máy tính của bạn được tổ chức, đồng bộ hóa và tích hợp. Khuôn khổ kiến ​​trúc bảo mật (security architecture framework) là một thành phần của kiến ​​trúc tổng thể của hệ thống. Nó được thiết kế và xây dựng để cung cấp hướng dẫn trong quá trình thiết kế toàn bộ sản phẩm hay hệ thống để vấn đề về bảo mật được tính đến và được đảm bảo trong quá trìn

HTTPS và SSL/TLS - giải thích cho trẻ em 5 tuổi thế nào?

Mình chém gió đấy, trẻ 5 tuổi còn đang tập đọc mà hiểu được cái này thì là thần đồng, là thiên tài, là mình cũng lạy. Nhưng bạn muốn đọc để  giải thích cho trẻ 5 tuổi ở cuối bài nhé :D 1. Đầu tiên : client gửi tới server một message hello để bắt đầu tiến trình handshake. Message này sẽ chứa một số thông tin, chẳng hạn như phiên bản SSL, Giải thuật mã hóa mà client support , và một chuỗi bytes ngẫu nhiên gọi là client random . Các bạn lưu ý chuỗi bytes này nhé, tác dụng của nó mình sẽ nói ở phần dưới. 2. Khi nhận được message hello từ client :  server cũng sẽ gửi lại cho client một message hello . Trong message này có chứa SSL certificate của server, Giải thuật mã hóa mà server chọn để thống nhất với Client (Cipher), và cả một chuỗi bytes ngẫu nhiên nữa được gọi là server random . (và một số cái linh tinh nữa, mình lược đi cho đỡ rối). Ở đây có một khái niệm mới, đó là SSL certificate. SSL và SSL certificate là 2 thứ khác nhau nha. SSL thì các bạn biết rồi, còn SSL certificate thì

[Secure coding - Part 4] Là developer cần làm gì để ứng dụng của mình an toàn và bảo mật hơn?

  Tổng quan về vấn đề bảo mật Trở lại với chuỗi bài viết về hướng dẫn lập trình an toàn cho lập trình viên, bài viết thứ tư trong series's post: Secure coding for developers sẽ tiếp tục với nội dung về các vấn đề liên quan đến các vấn đề: Error handling and Logging, Data protection. Việc xử lý lỗi hệ thống, lỗi ứng dụng hay lưu log ứng dụng là vấn đề cần được quan tâm vì nếu không được xử lý đúng cách ứng dụng sẽ lộ ra những thông tin nhạy cảm tạo điều kiện để kẻ tấn công thu thập thông tin và tấn công hệ thống. Vấn đề tiếp theo là việc bảo vệ dữ liệu (thông tin tối quan trọng của ứng dụng), nếu việc bảo dữ liệu không tốt sẽ gây ra những hậu quả nặng nề thậm chí ảnh hưởng đến tiền bạc và cả hoạt động của công ty. I. Error Handling and Logging Các yêu cầu trong việc thực hiện xử lý lỗi của ứng dụng, quản lý việc thông báo lỗi của ứng dụng tránh việc ứng dụng bắn lỗi gây ra việc lộ các thông tin nhạy cảm của ứng dụng. Việc lưu trữ log cũng cần thực hiện đúng yêu cầu, lưu đủ thông tin

Các công cụ khai thác "không chính thức" được OSCP "phê duyệt"

  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

[Secure coding - Part 3] Là developer cần làm gì để ứng dụng của mình an toàn và bảo mật hơn?

  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