1 điểm bởi GN⁺ 2024-01-20 | 1 bình luận | Chia sẻ qua WhatsApp
  • Tại Đức, một lập trình viên trong lúc điều tra log phần mềm phục vụ công việc đã phát hiện thông tin truy cập DB của nhà cung cấp và thông báo lại, nhưng tòa án cho rằng đó là hành vi hack
  • Phần mềm liên quan đang tạo kết nối MySQL tới máy chủ cơ sở dữ liệu của nhà cung cấp, bên trong chứa không chỉ dữ liệu của khách hàng do lập trình viên này phụ trách mà còn cả dữ liệu của mọi khách hàng của nhà cung cấp
  • Thông tin xác thực đã được hardcode dưới dạng văn bản thuần trong ứng dụng, lộ rõ đến mức thậm chí không cần decompile
  • Tòa án cho rằng chỉ riêng việc có mật khẩu đã đồng nghĩa tồn tại cơ chế bảo vệ, và hành vi vượt qua nó cấu thành hack
  • Phán quyết như vậy có thể làm nản lòng hoạt động nghiên cứu bảo mật chính đáng, đồng thời cho phép các công ty có bảo mật yếu kém né tránh trách nhiệm và khiến người dùng gặp rủi ro lớn hơn

Từ phát hiện đến bị khởi kiện

  • Đây là vụ việc làm dấy lên lo ngại rằng luật pháp Đức có thể biến nghiên cứu bảo mật thành một công việc đầy rủi ro
  • Một lập trình viên được giao điều tra phần mềm đang tạo ra quá nhiều thông điệp log
  • Trong quá trình điều tra, anh xác nhận rằng phần mềm đó đang tạo kết nối MySQL tới máy chủ cơ sở dữ liệu của nhà cung cấp
  • Cơ sở dữ liệu này không chỉ chứa dữ liệu của khách hàng do anh phụ trách mà còn có dữ liệu của mọi khách hàng của nhà cung cấp
  • Sau khi xác nhận điều này, lập trình viên đã lập tức báo cho nhà cung cấp; phía nhà cung cấp đã vá lỗ hổng nhưng vẫn tiến hành tố tụng hình sự đối với anh

Cơ chế bảo vệ theo cách nhìn của tòa án

  • Tranh điểm cốt lõi là liệu thông tin xác thực cơ sở dữ liệu được hardcode trong ứng dụng có đủ để được xem là biện pháp bảo vệ, qua đó biện minh cho cáo buộc hack hay không
  • Các thông tin xác thực này lộ ở dạng văn bản thuần và thậm chí không cần decompile
  • Tòa án kết luận rằng vì có mật khẩu nên tồn tại cơ chế bảo vệ, và hành vi vượt qua nó là hack

Rủi ro còn lại cho nghiên cứu bảo mật

  • Lý do nhiều người hy vọng bản án sẽ bị lật lại ở cấp phúc thẩm là vì, ngay cả khi biện pháp bảo vệ cực kỳ sơ sài, chỉ cần nó tồn tại thì theo luật Đức, nghiên cứu bảo mật cũng có thể bị xem là hành vi hack mang tính hình sự
  • Nếu nghiên cứu chính đáng bị chùn bước, doanh nghiệp có thể tiếp tục duy trì bảo mật không phù hợp mà vẫn né được trách nhiệm, và cuối cùng người dùng sẽ là bên chịu rủi ro

Nguồn bài gốc

1 bình luận

 
GN⁺ 2024-01-20
Ý kiến trên Hacker News
  • Tiêu đề bài viết hơi gây nhầm lẫn và gần như có vẻ câu view. Nếu tôi hiểu đúng, tội của anh ta là đã sử dụng thông tin xác thực cơ sở dữ liệu bị lộ để đăng nhập vào máy chủ cơ sở dữ liệu của bên thứ ba
    Nói cách khác, anh ta không bị truy tố chỉ vì “làm lộ” thông tin xác thực như tiêu đề gợi ý, mà đúng hơn là vì thực sự dùng chúng để vào xem bên trong

    • Thường thì cách duy nhất để biết một hệ thống là gì là kết nối vào và xem thử
      Điều này giống như khi được cấp thẻ ra vào tòa nhà thì ta giả định những cánh cửa mở được là những phòng mình được phép vào. Nếu đội bảo mật phát hiện tôi trong một phòng không được phép vào, thật khó nói đó là lỗi của tôi hay lỗi của người đã cấp cho tôi chiếc thẻ có quyền sai
      Nếu sau khi mở cửa và nhìn vào bên trong, tôi lập tức nhận ra “đây là nơi không được vào” rồi báo cho đội bảo mật, thì cũng đáng hỏi liệu tôi có đáng bị phạt hay không
    • Đúng vậy, anh ta đã đăng nhập vào máy chủ bằng thông tin xác thực được nhúng trong ứng dụng. Vì máy chủ chứa thông tin của người dùng khác, nếu anh ta dùng với mục đích xấu hoặc đăng nhập dù biết mình không có quyền truy cập, thì rõ ràng có thể là tội phạm
      Nhưng điểm mấu chốt là liệu anh ta có thể biết điều đó trước khi đăng nhập hay không. Nếu thông tin xác thực nằm trong ứng dụng, liệu có phải giả định rằng bảo mật của công ty lỏng lẻo đến mức có thể truy cập toàn bộ dữ liệu khách hàng không? Anh ta có quyền sử dụng ứng dụng, và ứng dụng dùng thông tin xác thực đó, nên nghĩ rằng bản thân cũng có thể dùng chúng không phải là một bước suy diễn quá xa
      Dù sao đi nữa, hệ quả của phán quyết này rõ ràng sẽ bất lợi cho an ninh máy tính. Từ nay, những người phát hiện lỗ hổng kiểu này có thể sẽ không báo cáo vì sợ bị trả đũa pháp lý
    • Không có gì khó hiểu cả. Chỉ là tiêu đề không đóng khung câu chuyện theo cách bạn thích mà thôi
      Từ góc nhìn của một lập trình viên, tự nhiên hơn là xem mật khẩu như thứ dùng để ngăn người không phải người dùng hợp lệ truy cập, chứ không phải để ngăn người dùng bình thường. Ngay từ đầu thông tin xác thực cũng không hề bị che giấu hay làm rối
      Khi đã rõ rằng người dùng không được phép truy cập, anh ta đã báo cho nhà cung cấp. Tôi có bỏ sót gì không? Một bên là lập trình viên đang làm việc của mình, bên kia là một công ty bị bẽ mặt và trả đũa, khiến những người có thể báo lỗi trong tương lai sợ hãi. Có vẻ rất rõ chuyện gì đang diễn ra
    • Nói rằng “anh ta thực sự dùng chúng để vào xem” là đúng, nhưng anh ta tin rằng cơ sở dữ liệu đó dành riêng cho khách hàng đó và chỉ chứa dữ liệu của khách hàng đó, mà khách hàng này đã cho phép anh ta truy cập dữ liệu của họ
      Có vẻ tên cơ sở dữ liệu cũng khiến anh ta nghĩ như vậy. Ngay khi nhận ra trong đó có dữ liệu của tất cả khách hàng, anh ta đã ngắt kết nối
    • Tôi ủng hộ khẩu hiệu Hacking Is Not A Crime
      Điều quan trọng là sau khi truy cập, anh ta đã làm gì với dữ liệu đó. Nếu không làm gì cả thì không nên coi là tội phạm; tội phạm chỉ nên được xác lập khi dữ liệu đó thực sự bị sử dụng với mục đích xấu
  • Đây là một vấn đề khá lớn ở Đức. Vì các điều khoản StGB 202 trở đi được trích dẫn, nghiên cứu bảo mật trong khu vực tư nhân trên thực tế đã trở nên bất khả thi, hoặc ít nhất là rất kém hấp dẫn
    Đã có gần 20 năm khoảng trống, khiến rất ít kỹ sư trẻ quan tâm hoặc được đào tạo trong lĩnh vực này. Những tập đoàn lớn giàu nhất đã vét hết nhân lực có thể tìm được, còn nhân tài hàng đầu thì ra nước ngoài. Vì vậy các doanh nghiệp vừa và nhỏ, vốn chiếm phần lớn doanh nghiệp Đức, bị hack ngày càng nhiều mỗi ngày. Không ai kiểm toán cả. Ngày nay, mọi thứ kết nối mạng đều là rủi ro bảo mật
    Tôi cho rằng kỳ vọng tòa cấp cao sẽ lật lại phán quyết là rất ngây thơ. Bị cáo có thể sẽ phải lãng phí nhiều năm trời đi từ AG lên LG, OLG rồi BGH. Tôi ước tính chi phí cũng sẽ bay mất khoảng 100.000 euro. Rốt cuộc để làm gì? Công ty không bảo vệ dữ liệu của mình đúng cách, và khi được thông báo thì “cảm ơn” bằng cách lôi người ta ra tòa
    Lời khuyên của tôi là thế này: nếu không có chương trình bug bounty rõ ràng, hoặc đó không phải công ty của bạn, hoặc công ty đó không yêu cầu rõ ràng bằng văn bản và trả tiền cho việc đó, thì đừng biến vấn đề đó thành vấn đề của mình. Hãy kiềm chế hội chứng người Samari nhân hậu, xóa mọi tệp đi và đừng nói với ai. Đặc biệt là ở nơi làm việc thì càng không nên nói. Khi kiện tụng bắt đầu, người bị hỏi sẽ nói “À, Mike bên DevOps phát hiện ra nó trong bản hex dump”, và bạn sẽ phải hối hận
    Một số cao thủ an toàn thông tin kỳ cựu ở Đức tức giận vì vấn đề này đến mức từ chối giúp đỡ ngay cả khi cơ quan chính phủ gặp sự cố. Kiểu như hãy học qua đau đớn

  • Vụ này đã kéo dài vài năm rồi
    Mùa hè năm ngoái, tòa đã bác vụ án của công tố. Trong hệ thống này, công tố nộp vụ án lên tòa, tòa xem xét nhanh và nếu thấy rõ ràng yếu thì có thể bác trước khi lên lịch xét xử; việc này khá hiếm. Công tố đã khiến quyết định đó bị đảo ngược ở tòa cấp cao hơn, nên phiên xử diễn ra tại cùng tòa cấp dưới, nhưng do một thẩm phán khác với người đã bác vụ án ban đầu phụ trách
    “Theo quyết định ngày 10 tháng 5 năm 2023 của Tòa án địa phương Jülich, thủ tục hình sự đối với nhà nghiên cứu bảo mật đã bị bác bỏ. Tòa cho rằng không cấu thành tội hình sự vì dữ liệu mà nhà nghiên cứu bảo mật truy cập không được bảo vệ đầy đủ. ‘Chỉ dữ liệu được bảo vệ đặc biệt trước truy cập trái phép mới thuộc phạm vi bảo vệ của tội danh này. Điều đó giả định rằng đã có các biện pháp khách quan phù hợp để ngăn truy cập dữ liệu’, quyết định của tòa nêu. ‘Tòa không đồng ý với quan điểm của công tố rằng bản thân việc bảo vệ bằng mật khẩu là đủ. Chẳng hạn, nếu mật khẩu quá đơn giản hoặc được sử dụng theo cách chuẩn hóa trong một ứng dụng cụ thể, mật khẩu không phải lúc nào cũng cung cấp khả năng bảo vệ dữ liệu hiệu quả. Trong những trường hợp như vậy, việc cung cấp quyền truy cập dữ liệu không cấu thành tội phạm.’”
    “Qua điều tra riêng về phần mềm Modern Solution, heise online có thể xác nhận rằng phần mềm này thực sự chứa mật khẩu mặc định được nhúng sẵn. Điều này có nghĩa là bất kỳ ai kiểm tra phần mềm có thể tải xuống tự do từ trang web của công ty đều có thể truy cập dữ liệu trên máy chủ của Modern Solution.”

  • Không, anh ta bị kết tội vì đã dùng các thông tin xác thực đó để kết nối vào cơ sở dữ liệu. Tôi không biết luật Đức, nhưng ít nhất ở Anh thì đây rõ ràng là vi phạm Computer Misuse Act, nên kết cục của vụ này là hiển nhiên
    Dù thích hay không, nếu bạn ở vị trí làm kiểu nghiên cứu như vậy thì ít nhất cũng phải biết những điều cơ bản của pháp luật

    • Gọi là “kiểu nghiên cứu như vậy” thì hơi quá, việc của anh ta là “xem xét một phần mềm ghi ra quá nhiều thông điệp log”
      Nghe có vẻ nhà phát triển này không làm nghiên cứu bảo mật mà đang điều tra lỗi. Việc kết nối vào cơ sở dữ liệu, nhận ra đó là gì, rồi lập tức ngắt kết nối và báo cáo có trách nhiệm không nên dẫn đến bị trừng phạt
      Như người khác đã nói, làm thế này chỉ khuyến khích người ta bán kiến thức đó cho những người thực sự sẽ “lạm dụng” nó
    • Bản thân việc mở ứng dụng đã là “sử dụng” các thông tin xác thực đó rồi. Vậy tất cả khách hàng của công ty đó cũng có tội hack sao?
      Tôi không thấy khác biệt nằm ở đâu. Nếu là vi phạm điều khoản dịch vụ thì có thể, nhưng gọi đây là “hack” thì còn xa lắm
      Có mật khẩu không có nghĩa là họ đã cố ngăn người khác. Chính họ đã phân phối kèm mật khẩu đó
      Giống như khi vào một tòa nhà, họ đưa bạn thẻ khóa và nói “đừng đi vào những nơi không được phép”, nhưng hóa ra đó là chìa khóa vạn năng. Làm sao ngay từ đầu bạn biết được thẻ đó sẽ mở cả những nơi lẽ ra nó không được mở
      Tôi cũng có thông tin xác thực dịch vụ Google, nhưng chúng chỉ cho phép tôi truy cập phần của mình
    • Tôi không chắc mọi chuyện đơn giản như vậy. Theo tôi biết, anh ta được khách hàng nhờ điều tra vì sao hệ thống bị tràn ngập bởi một loại dữ liệu nào đó
      Anh ta chạy connector của một dịch vụ khác có vẻ là nguồn phát sinh dữ liệu đó, và quan sát thấy tường lửa mở một kết nối dạng văn bản thuần tới máy chủ MySQL từ xa. Khi xem xét, anh ta thấy thông tin xác thực được dùng là giống nhau cho mọi tenant trong MySQL DB. Vì vậy thứ bị lộ không chỉ là dữ liệu của khách hàng, mà là dữ liệu của tất cả tenant
      Sau đó, theo tôi hiểu, anh ta tạo hash dữ liệu người dùng và xuất nó ra để báo cáo cho nhà chức trách, đồng thời cho phép người dùng kiểm tra xem họ có nằm trong hệ thống mà họ nên xem là đã bị xâm phạm hay không. DB đó đã làm lộ dữ liệu của khoảng 700.000 người dùng cuối. Anh ta cũng thông báo vấn đề này cho công ty vận hành DB
      Nhà cung cấp connector đó đã phát hành client mới dùng TLS, và anh ta cũng vượt qua nó để chứng minh vấn đề vẫn còn tồn tại
      Anh ta còn bị cáo buộc đã dịch ngược phần mềm client để lấy mật khẩu, nhưng nếu tôi nhớ không nhầm thì anh ta nói rằng mình chỉ mở tệp bằng Notepad
    • Nếu thông tin xác thực cơ sở dữ liệu được nhúng trong ứng dụng, thì việc ứng dụng đăng nhập vào máy chủ của nhà cung cấp có vẻ là hành vi được thiết kế sẵn. Vậy có phải tất cả người dùng của nhà cung cấp đó cũng nên bị truy tố vì hack không?
    • Đọc nội dung bài thì khó nói là rõ ràng như vậy. Nhà phát triển phát hiện thông tin xác thực cơ sở dữ liệu khi đang điều tra vấn đề, và vì phần mềm kết nối trực tiếp nên có vẻ anh ta đã giả định rằng kết nối cơ sở dữ liệu đó là single tenant hoặc bị giới hạn theo quyền của người dùng
      Khi nhận ra có thể truy cập nhiều dữ liệu hơn dự kiến, anh ta đã ngắt kết nối
      Tôi cũng từng làm đúng điều tương tự trong một tình huống tương tự. Có một nhà cung cấp phần mềm desktop gặp vấn đề, tôi thấy thông tin xác thực cơ sở dữ liệu được lưu dạng văn bản thuần trong tệp cấu hình rồi kết nối thử. Trong trường hợp của tôi, cơ sở dữ liệu đó là single tenant dành riêng cho công ty chúng tôi, nên tôi xử lý được việc mình cần
      Khi áp dụng luật cho những vụ như thế này, rõ ràng ý định phải được xét đến chứ? Tôi không thấy nhà phát triển này có ý định truy cập vào một hệ thống bị hạn chế
  • Có lẽ luật kiểu đó cần được viết lại. Ý định mới là quan trọng, và “hacker” này có vẻ không hề muốn gây hại
    Công ty bị bẽ mặt vì lỗ hổng bảo mật bị phơi bày, và họ muốn trừng phạt người đã công khai nó

    • Đúng vậy. Sẽ tạo ra hiệu ứng răn đe khiến hệ thống ở Đức kém an toàn hơn, và các nước khác nằm ngoài quyền truy tố của Đức sẽ khai thác điều đó
      Chỉ riêng vụ này cũng khiến tôi, với tư cách nhà phát triển, không muốn làm việc ở Đức; nếu là lĩnh vực bảo mật thì lại càng không
    • Đồng ý. Bản án có tội này thực chất là hình phạt vì đã thách thức chủ nghĩa lấy doanh nghiệp làm trung tâm và khiến họ mất mặt
      Họ muốn “nông dân” biết vị trí của mình và đừng nhìn qua cửa sổ của giới quý tộc. Trừ khi các luật sư bằng cách nào đó chiếu được ánh sáng dư luận vào, nhà nước hầu như luôn đứng về phía có nhiều tiền nhất. Vì vậy những việc như thế này nên làm ẩn danh
  • Tôi từng làm một startup thực phẩm ở Hà Lan
    Chúng tôi làm việc với PostNL, một đơn vị lớn phụ trách gửi thư và từng là tổ chức thuộc chính phủ. Mỗi tuần chúng tôi tải đơn hàng lên hệ thống của họ và có thể xem lịch sử của mình
    Rồi một ngày nọ, đột nhiên chúng tôi có thể truy cập lịch sử của tất cả khách hàng khác và xuất dữ liệu người dùng. Nhiều bên trong số đó là đối thủ trực tiếp, và danh sách mailing của họ hẳn sẽ khá có giá trị với chúng tôi
    Đồng sáng lập của tôi đã xuất toàn bộ dữ liệu của đối thủ Marley Spoon, bên đã gọi được nhiều vốn hơn, cùng vài dữ liệu khác ra Excel. Khi anh ấy nói với tôi, tôi bảo xóa ngay lập tức. Có thể thú vị đấy, nhưng không nên tạo rủi ro pháp lý. Tuy vậy, nếu dùng nó, có lẽ chúng tôi đã có thể tăng trưởng 10–30% chỉ trong vài tuần
    Dù có nghĩa vụ theo luật EU, họ chưa bao giờ báo cáo
    Rốt cuộc, nếu bạn có được chìa khóa vào lâu đài thì có lẽ tốt hơn là đừng dùng. Hoặc cũng có thể dùng
    Chúng tôi đã có thể dùng nó trong đàm phán giá, và có lẽ đáng ra nên làm vậy. Vài tháng sau đó họ gần như tăng gấp đôi giá của chúng tôi và không hề khoan nhượng. Chưa kể họ xử lý sai 3–8% đơn hàng mà cũng không hoàn tiền
    Nhưng thay vào đó chúng tôi chuyển sang vài dịch vụ giao hàng khác, và mỗi bên cũng đều có lỗi riêng

    • Nếu sợ bị trả đũa, bạn có thể báo ẩn danh cho Autoriteit Persoonsgegevens và để họ điều tra
      Ảnh chụp màn hình có bằng chứng dữ liệu cá nhân bị rò rỉ chắc chắn sẽ hữu ích, và tôi không nghĩ PostNL đã sửa cái hệ thống tệ hại đó
      Theo luật Hà Lan, nếu đồng nghiệp của bạn biết mình không được phép truy cập mà vẫn tải dữ liệu vượt quá phạm vi cần thiết để xác minh có rò rỉ hay không, thì người đó đã phạm tội
      Nếu bạn “dùng” thông tin này trong đàm phán thì đó là tống tiền, đặc biệt với một công ty lớn như vậy và gần như không có đối thủ thực sự thì đó tuyệt đối không phải là việc bạn muốn làm. Họ sẽ báo cảnh sát, và bạn sẽ tiêu đời
  • Nghe giống một vụ từng xảy ra ở nơi tôi sống
    https://www.techdirt.com/2022/02/25/turns-out-it-was-actuall...
    Vụ “hack” đó là giải mã số an sinh xã hội được mã hóa bằng Base64

    • Thông điệp nằm trong phần Base64 đã mã hóa trong bài đó khá thú vị, và làm tôi nhớ đến một ý nghĩ trước đây
      Hãy tưởng tượng các lập trình viên lười biếng dán đủ thứ vào các trình giải mã Base64 trực tuyến. Trong các payload đó sẽ chứa bao nhiêu thứ nhỉ
      Vận hành một trang như base64decode.org hẳn sẽ là một honeypot tuyệt vời
    • Đúng vậy, đây là vụ tôi nghĩ đến ngay khi thấy tiêu đề này. Không hiểu sao vừa bình luận chuyện này là tôi bị downvote ngay
      Nếu dữ liệu thực sự được mã hóa thì đã ổn, nhưng mã hóa Base64 không phải là mã hóa mật mã. Base64 có thể được giải mã rất dễ dàng: https://developer.mozilla.org/en-US/docs/Glossary/Base64#the...
  • Nhiều vụ “hack” giống như chuyện một kẻ ngốc để cửa trước mở toang
    Nếu để cửa trước mở toang rồi bị trộm, công chúng sẽ không thông cảm, nhưng khi các công ty tiết kiệm tiền và không làm gì để cập nhật, duy trì, thực thi các thực hành bảo mật cơ bản tốt nhất, thì người ta lại la ó hacker

    • Không phải vấn đề “thông cảm”, mà là vấn đề tội phạm
      Nếu bạn để cửa trước mở toang và tôi bước vào lấy trộm đồ, thì tôi đã phạm tội. “Cửa đang mở” không phải là cái cớ
    • Dù bạn để cửa trước mở toang rồi bị trộm, đó vẫn là tội phạm
      Tôi đáng bị chê trách, nhưng người đã trộm của tôi cũng phải chịu hình phạt thích đáng
    • Không biết bạn sống ở đâu, nhưng việc ai đó bước vào chỉ vì tôi để cửa mở không phải là chuyện bình thường
      Kể cả khi họ tuyên bố rằng họ “chỉ cố kiểm tra xem mọi thứ có an toàn không” cũng vậy
  • Chẳng phải đây là mặt trái của luật Người Samari nhân hậu sao? Kiểu như thấy gì thì đừng nói gì, cũng đừng làm gì
    Nếu việc tìm ra những vấn đề như thế này là bất hợp pháp, tôi tự hỏi liệu sau khi nhận ra có thể có vấn đề rồi dừng lại và bán khống cổ phiếu công ty đó thì có hợp pháp không

    • Miễn là không dùng thông tin nội bộ, kiểu bán khống đó hoàn toàn hợp pháp. Những công ty như Hindenburg Research về cơ bản làm những việc tương tự
      Vấn đề bạn sẽ gặp nếu thật sự thử làm là nhà đầu tư hầu như không quan tâm đến các vấn đề bảo mật. Vì vậy dù công bố lỗ hổng, giá cổ phiếu có lẽ cũng không giảm. Hơn nữa công ty này dường như cũng không phải công ty đại chúng. Tôi không biết tiếng Đức nên không nên khẳng định chắc, nhưng có lẽ là bên này: https://www.modernsolution.net/
    • Có lẽ dùng Tor + Twitter là được, nếu thật sự có thể đăng ký ở đó qua Tor
      Kiểu như: “Xin chào, tôi tình cờ phát hiện có một mật khẩu ở offset X của ứng dụng này. Trong ảnh chụp hex dump này có thể thấy mật khẩu. Bên cạnh còn có tên người dùng và host, cùng dấu hiệu rõ ràng cho thấy đây là kết nối SQL, nhưng tôi không thể xác nhận mật khẩu đó là gì. Đừng dùng tên người dùng và mật khẩu này để kết nối tới IP này. Cảm ơn!”
    • Những lỗi như vậy có thể không bị phát hiện trong nhiều năm, nên để bán khống thành công có lẽ cần thúc đẩy thêm một chút
      Ngoài ra, xét theo các công ty Mỹ, ngay cả rò rỉ dữ liệu quy mô lớn hay bị xâm nhập cũng thường không ảnh hưởng tiêu cực đến tài chính công ty
  • Điều 202a của Bộ luật Hình sự viết như sau
    https://www.gesetze-im-internet.de/stgb/__202a.html
    Đại khái là “hành vi giành được quyền truy cập, cho bản thân hoặc người khác, vào dữ liệu được bảo vệ theo cách đặc biệt trước truy cập trái phép”
    apparently mật khẩu hardcode được nhúng trong client cũng có vẻ thuộc trường hợp này

    • Đúng vậy. Đây nổi tiếng là một đạo luật cực tệ, lẽ ra ngay từ đầu không nên được thông qua
      Nhưng thực tế là vậy, có lẽ đến khoảng năm 2050 họ mới sửa