Lỗi kỹ thuật hay làm ẩu?

Đợt rồi tôi có 1 project nhỏ - thử cào dữ liệu toàn bộ các báo điện tử / trang thông tin tiếng Việt để nhằm mục đích test phân tích data. Thực ra là tôi muốn tìm hiểu xem có kiếm được cái công việc nào sáng lạn hơn là ngồi code không

Trong quá trình làm, phải bóc dữ liệu, tôi chọn cách đơn giản với css selector vs xpath cho nhanh, nhưng tự nhiên phát hiện ra mấy bug thú vị của 1 vài trang báo điện tử khá hay ho.

Sau khi gửi email kèm bằng chứng bug tới các bên có liên quan, sau khi xác nhận fixed từ các bên, nay chia sẻ vài câu chuyện zui mà có thể nó không khác sự thực

1/ Trang báo đầu tiên - 1 tờ báo lớn và có uy tín trong 1 ngành có liên quan tới tiền bạc. Đứng sau hệ thống này là 1 công ty kỹ thuật chuyên product có phần mềm CMS nổi tiếng - cũng đã được áp dụng trong nhiều đơn vị ở Việt Nam.
  • Lỗi củ chuối 1: Trong trang category list, khi bóc html document tôi thấy có config 1 cái key gì đó khi được thể hiện ở trong đoạn git conflict (chắc relsove bằng cách comment đi) => điều tra được đó là key dùng push vào CDN (ối dời ơi 1)
  • Lỗi củ chuối 2: Google Search Dorking - không cần nói nhiều lỗi này, tuy nhiên, khi search tôi còn chèn được cả 1 đoạn image src vào trong body result trang search
    • tới đây: tôi nghĩ thử hay mình thử viết 1 đoạn js console để nó push cái image này vào của CDN của trang báo này xem sao nhỉ -> kết quả là được.
    • Vậy thì câu hỏi đặt ra là nếu hình ảnh đó là lừa đảo, bôi nhọ đem đi share thì với uy tín của trang báo này liệu có phải là risk lớn không
    • Nghĩ vậy, tôi thử tạo 1 lệnh push 1 file html lên CDN, thường các CDN không khuyến khích việc đặt file HTMl lên CDN, tuy nhiên, liều, tôi thử xem -> ôi má ơi nó được luôn, vậy là đến đây tôi có luôn 1 trang web lừa đảo hoặc bất kì thứ gì đó được đặt trong 1 trang báo uy tín hẳn hoi nếu tôi muốn
  • bài học: luôn quét key, credentials khi deploy. Các thông tin nhạy cảm này nên được config ở 1 file riêng và chỉ có devops có quyền config vô, dev thì thôi để tránh lộ (giải quyết được vấn đề conflict)

2/ Trang báo thứ 2 - cũng là 1 tờ báo rất lớn, uy tín và có tên tuổi, thuộc 1 bộ lớn và có rất nhiều traffic
  • Đứng sau cũng là 1 công ty kỹ thuật chuyên product CMS, nhưng tôi đoán khác trang báo 1, vì nếu là product solution, trong phần mềm không tránh được cách bố trí, sắp xếp hoặc thậm chí là classname, id giống hệt nhau. Nhưng đằng này khác hoàn toàn nên tôi đoán là không phải
  • Trang này dính lỗi củ chuối hơn
    • Lỗi 1: Ối dời ơi ông dev nào comment nguyên đoạn chat (chắc với techlead - nội dung cơ bản thì là copy lại url PHP Myadmin ông lead gửi) vào source của web luôn. Lỗi này thì đến Ạ với quy trình review code và deploy 😞
    • Lỗi 2: Các thông tin phpmyadmin kia là thật - truy cập được với quyền user admin luôn
      • Vậy thì nếu tôi là 1 người vô đạo đức - tôi đã có thể drop cả database
      • Vậy thì nếu tôi là 1 người vô đạo đức - tôi đã ở 1 bài báo nào đó tôi chèn vài thông tin linh tinh vào ?
      • Vậy thì nếu tôi là 1 người vô đạo đức - tôi đã đọc trộm được thông tin chat chit nội bộ
      • Thôi trang này, tôi đến lậy ạ các anh dev ẩu tả không chịu được
      • Vậy thì với những gì tôi có thể làm được với database -> nếu tôi làm điều xấu - đăng tải 1 nội dung lừa đảo -> dùng link trang báo đó để đi loè người thì chắc chắn sẽ có nhiều câu chuyện thương tâp
  • Bài học:
    • đừng coi thường khâu review code
    • deploy rồi thì nên vào trang mà test lại, đừng chỉ có nhìn pipeline
    • lại 1 lần nữa, câu chuyện đạo đức làm nghề - khi 1 anh dev ẩu paste thông tin nhạy cảm vào file công việc (tôi đoán là file theme) và push lên repo, anh techlead chả buồn review auto merge -> năm ngoái khi thực hiện training nghiệp vụ cho member, tôi rất nhiều lần nói với các em của tôi câu chuyện này trong blog Social hacking
3/ Trang báo thứ 3 - trang này thì bình thường, nội dung tạp chí của 1 viện ít người để ý
  • Đứng sau cũng là 1 công ty kỹ thuật chuyên product CMS - tôi đoán thế vì khi bóc tách html - các đoạn classid và classname tôi thấy trùng với vài trang khác
  • Ôi thì rất lắm lỗi
    • Trang thứ 2 thì phpmyadmin còn đặt htpass, trang này còn không thèm đặt
    • User Database là admin / Pass database là kiểu này: ví dụ tên báo là: tapchinguyenanhung.com thì tên password các anh ấy đặt là Tapchinguyenanhung1234! (chán chả buồn nói) - mà nó zui ở chỗ, cái pass này đáp ứng đầy đủ nguyên tắc 1 mật khẩu mạnh cơ bản: có chữ hoa, chữ thường, có số, có kí tự đặc biệt và dài hơn 6 kí tự 😂
      • và với user admin thì thập chí tôi còn sync được database này sang 1 hệ khác luôn ấy
    • Google Dorking vẫn dính tùm lum. Lỗi này thì tôi tin là nhiều trang bị
...

Thật ra con số nó không dừng ở 3, nhưng tôi mỏi tay rồi nên không list nữa. Đến bây giờ thì tôi vẫn nghèo vì tôi vẫn không làm liều sử dụng mấy thông tin tôi kiếm được vào mục đích xấu. Vẫn phải đi bid mấy dự án 50-100$ về code thêm kiếm tiền mua khoai tây chiên cho cu Gấu ăn. Kiến thức share free, nếu bạn có việc gì hay ho lương thiện thì ới tôi với để tôi mua thêm khoai tây chiên cho con zai tôi ăn ạ. full-width

Post a Comment

Mới hơn Cũ hơn