Chào mọi người.
Hôm nay, thay vì nói về hack và đột nhập vào hệ thống như chúng ta thường làm,
chúng ta sẽ nói về bảo mật và cụ thể là cách bảo mật các trang web, ứng dụng web, ứng dụng di động,
v.v.
Rõ ràng, các vụ hack và vi phạm có tác động tiêu cực rất lớn đến các công ty từ việc đánh mất lòng tin của khách hàng
đến tổn thất tài chính.
Dữ liệu người dùng bị rò rỉ, các vấn đề pháp lý và danh sách vẫn tiếp tục.
Bây giờ, nếu bạn tìm kiếm nhanh trên Google về cách bảo mật trang web hoặc ứng dụng của mình, bạn
sẽ nhận được rất nhiều rác.
Tôi thực sự rất thất vọng về các bài viết về clickbait mà thực sự không giải thích hoặc đưa ra bất kỳ thông tin hữu
ích nào.
Hầu hết trong số họ đề xuất rằng bạn nên sử dụng các bản sao lưu, bạn có mật khẩu mạnh và đảm bảo rằng bạn sử dụng HTTPS.
Nhưng các bản sao lưu không bảo mật trang web của bạn, chúng chỉ giúp bạn khôi phục.
Ngoài ra, sử dụng ETP sẽ mã hóa thông tin liên lạc, nhưng nó không thực sự bảo mật trang web.
Một mẹo hữu ích duy nhất là sử dụng mật khẩu mạnh.
Nhưng hầu hết các hacker sẽ không ngồi xuống và cố gắng đoán mật khẩu như bạn thấy trong các bộ phim Hollywood.
Họ sẽ dựa vào các lỗ hổng và điểm yếu trong ứng dụng của bạn và họ sẽ khai thác chúng
để có quyền truy cập vào nó, bất kể bạn sử dụng mật khẩu nào.
Ngay cả khi bạn có một mật khẩu rất, rất phức tạp, ngay cả khi bạn đang sử dụng HTTPS và ngay cả khi bạn có bản sao lưu, thì rất nhiều điều
này thực sự không liên quan.
Ngoài ra, nó không thực sự quan trọng bạn đã lưu trữ ứng dụng ở đâu, cho dù bạn sử dụng A. W hoặc bất kỳ nhà cung cấp dịch vụ đám mây
nào khác và bạn đang triển khai ứng dụng này như thế nào không quan trọng.
Nếu bạn đang sử dụng Kubernetes hoặc nếu bạn đang sử dụng Docker, điều đó không thực sự quan trọng.
Nó thực sự rất, rất đơn giản.
Nếu bạn có một ứng dụng web dễ bị tấn công, thì tin tặc sẽ sử dụng các lỗ hổng hoặc điểm yếu này để giành
quyền truy cập vào ứng dụng này.
Vì vậy, dù sao, đủ ranting.
Hãy nói về cách thực sự bảo mật các trang web và ứng dụng.
Trước hết, trước khi chúng ta bắt đầu nói về nó, điều rất quan trọng là phải hiểu rằng
việc đạt được 100% bảo mật là không thể.
Tất cả những gì chúng tôi đang cố gắng làm là cải thiện tính bảo mật của các ứng dụng của mình và đảm bảo rằng chúng
an toàn nhất có thể.
Như đã nói, bốn cách tiếp cận sau đây sẽ giúp bạn cải thiện tính bảo mật cho các ứng dụng của mình, bất
kể chúng là loại ứng dụng nào và bất kể chúng được cài đặt ở đâu.
Như tôi đã nói, không quan trọng nếu bạn cài đặt chúng trên Amazon hay bất kỳ nơi nào khác trên WIC hay bất kỳ thứ gì
khác và không quan trọng bạn đang triển khai nó như thế nào nếu bạn đang sử dụng Docker, v.v.
Vì vậy, điều đầu tiên bạn nên làm là đảm bảo rằng bạn đang viết mã an toàn theo cách này.
Ứng dụng của bạn được xây dựng từ đầu để an toàn và không giới thiệu bất kỳ lỗi hoặc lỗ hổng bảo mật nào có thể
bị tin tặc khai thác để giành quyền truy cập.
Bây giờ, điều này sẽ rất tuyệt nếu bạn có thể làm được, nhưng vấn đề là nói thì dễ hơn làm vì các nhà
phát triển cần được đào tạo và dạy các phương pháp mà tin tặc sử dụng để khai thác hệ thống và giành quyền truy
cập.
Và ngay cả khi bạn làm điều đó, phần lớn thời gian các nhà phát triển dựa vào thư viện của bên thứ ba và toàn bộ ứng dụng có thể
được viết bởi người khác.
Do đó, bạn chỉ đơn giản là không thể viết mã bảo mật vì bạn thực sự không phải là người viết hoặc nhà phát
triển ứng dụng này.
Điều này đưa tôi đến điểm thứ hai.
Xem lại mã.
Điều này thực sự rất tốt, ngay cả khi bạn tự viết ứng dụng và ngay cả khi bạn đã chắc chắn
rằng mình viết mã an toàn, thì bạn nên yêu cầu các nhà phát triển khác hoặc một nhóm khác xem
xét mã đó.
Chỉ trong trường hợp các nhà phát triển viết ứng dụng bỏ sót điều gì đó hoặc bỏ qua điều gì đó, thì
nó sẽ bị bắt ở giai đoạn xem xét.
Ngoài ra, nếu bạn đang sử dụng mã được viết bởi các nhà phát triển khác hoặc thư viện của bên thứ ba, thì một lần
nữa, đánh giá mã sẽ khắc phục sự cố này vì bạn có thể xem lại và mọi thứ.
Và một lần nữa, điều này thực sự rất tốt vì bạn đang thực sự xem xét từng dòng một và đảm bảo
rằng không có gì dễ bị tấn công hoặc sẽ cho phép tin tặc khai thác ứng dụng của bạn và giành quyền truy cập.
Bất lợi chính ở đây là nếu bạn có một cơ sở mã lớn, điều này có thể rất tốn thời
gian và cũng có thể rất tốn kém.
Theo tôi, cách tiếp cận thứ ba, rất cần thiết là làm một bài kiểm tra bút.
Trong một bài kiểm tra bút.
Về cơ bản, bạn thuê một nhóm tin tặc có đạo đức để thử và hack ứng dụng của bạn.
Những tin tặc có đạo đức này sẽ tiếp cận ứng dụng của bạn giống như cách mà các tin tặc Mũ đen làm.
Họ sẽ cố gắng thu thập càng nhiều thông tin càng tốt và khám phá tất cả các điểm yếu và lỗ hổng và xem liệu họ có thể khai
thác chúng để có được quyền truy cập hay không.
Cuối cùng, khi hoàn tất, họ sẽ cung cấp cho bạn một báo cáo chi tiết về mọi thứ họ tìm thấy để bạn
có thể chuyển nó cho các nhà phát triển của mình và vá bất kỳ lỗ hổng nào mà họ phát hiện ra.
Ưu điểm chính của phương pháp này là bạn có thể kiểm tra các bề mặt tấn công mà bạn không thể kiểm tra bằng
các phương pháp khác, chẳng hạn như máy chủ đang chạy ứng dụng web của bạn và liên kết yếu nhất, đó là các
nhân viên.
Vì vậy, những tin tặc này, những tin tặc có đạo đức, thậm chí có thể sử dụng kỹ thuật xã hội và xâu chuỗi nó với các cuộc tấn công đơn giản
hơn hoặc các lỗ hổng đơn giản hơn mà chúng có thể tìm thấy trên hệ thống của bạn để xem liệu chúng có thể sử dụng chúng để truy cập
hay không.
Những bất lợi ở đây là nó có thể hơi tốn kém và nó không phải là bằng chứng trong tương lai.
Ý tôi là nếu bạn nhận được ứng dụng của mình được kiểm tra ngay hôm nay bởi một tin tặc có đạo đức thực sự tốt và sau
đó đảm bảo rằng bạn vá mọi lỗ hổng duy nhất mà họ tìm thấy, điều này chỉ có nghĩa là ứng dụng web của bạn ngày nay được bảo
mật.
Nó không đảm bảo rằng nó sẽ vẫn an toàn trong tháng tới hoặc năm tới, bởi vì mọi thay đổi bạn thực
hiện, mọi tính năng bạn đẩy hoặc thậm chí mọi lỗi hiển thị mà bạn sửa đều có thể tạo ra các lỗi hoặc điểm
yếu bảo mật khác mà sau đó có thể được sử dụng xâm nhập vào ứng dụng của bạn.
Không chỉ vậy, một lần nữa nếu bạn đang cập nhật lại phần mềm hoặc plugin của bên thứ ba, tất cả những điều đó
có thể tạo ra các lỗ hổng bảo mật và một bài kiểm tra sẽ không thể phát hiện ra điều đó bởi vì bạn chỉ thực hiện Panthers
hôm nay và những thay đổi trong tương lai này là sẽ không được kiểm tra.
Cách tiếp cận thứ tư, thực sự có thể giải quyết vấn đề này, là có một chương trình tiền thưởng lỗi.
Một chương trình tiền thưởng lỗi về cơ bản là một lời mời đến tất cả các hacker có đạo đức trên toàn thế giới để kiểm
tra ứng dụng của bạn và gửi phát hiện của họ.
Và bạn sẽ chỉ trả tiền cho các lỗi hợp lệ hoặc báo cáo hợp lệ.
Lợi ích chính là ở đây, như bạn đã đoán, có thể là bây giờ, bạn đang nhận được một số lượng
lớn tin tặc kiểm tra ứng dụng của mình, vì vậy khả năng họ tìm thấy lỗ hổng bảo mật cao hơn.
Và đó thực sự là bằng chứng trong tương lai vì miễn là bạn có danh sách tiền thưởng lỗi đó trực tuyến, những tin tặc này sẽ
luôn tiếp tục kiểm tra ứng dụng của bạn và bạn thúc đẩy họ bằng tiền thưởng.
Vì vậy, đây có thể là bất cứ thứ gì, từ áo phông đến các giải thưởng tiền tệ thực sự.
Để đảm bảo rằng họ thực sự sẽ tiếp tục thử nghiệm ứng dụng của bạn.
Vì vậy, ngay cả khi bạn đang đẩy các thay đổi mới, tính năng mới hoặc cập nhật nội dung, điều đó không thực
sự quan trọng vì tin tặc sẽ tiếp tục kiểm tra ứng dụng của bạn với hy vọng tìm ra lỗi và nhận tiền thưởng cho phát hiện của họ.
Đó là lý do tại sao các công ty lớn như Facebook và Google sử dụng các chương trình tiền thưởng lỗi này, mặc dù họ tuân theo
tất cả các cách tiếp cận khác.
Như tôi đã nói, họ vẫn sử dụng điều này để đảm bảo rằng hệ thống của họ luôn an toàn nhất có thể và
không có lỗi nhất có thể.
Những bất lợi ở đây, trước hết, thật khó để đảm bảo rằng tất cả các bề mặt tấn công đều được che phủ.
Và thứ hai là, rất nhiều công ty không có phạm vi tiếp cận như Google và Facebook, vì vậy họ không thể thực
sự quảng cáo số tiền thưởng lỗi của họ tốt như các công ty lớn.
Họ không thể có nhiều tin tặc có đạo đức để kiểm tra trang web của họ.
Việc tạo ra các chương trình tiền thưởng lỗi này và xác thực các báo cáo đã gửi là một thách thức đối với họ.
Nhưng điều này được giải quyết bởi các nền tảng tiền thưởng lỗi mà chúng ta có ngày nay, chẳng hạn như tiền thưởng lỗi, dotcom
và các nền tảng khác.
Bug Bounty thực sự là một công ty chị em của bảo mật đó.
Vì vậy, ý kiến của tôi có thể hơi thiên lệch một chút, nhưng tôi khá chắc chắn rằng giá của chúng tôi là cạnh tranh nhất và chúng
tôi cung cấp cùng một dịch vụ.
Vì vậy, dù sao, tôi được bao gồm trong tất cả mọi thứ ở đó.
Bạn có quyền lựa chọn.
Bạn có thể kiểm tra bất cứ thứ gì bạn muốn, và tôi xin lỗi nếu tôi thực sự khiến bạn nhầm lẫn với cách tiếp cận mùa thu.
Đó là tôi vừa đề cập, nhưng theo ý kiến của tôi, lý tưởng nhất là bạn nên làm theo tất cả bốn cách tiếp cận
này, nếu bạn có thể.
Điều này có thể khá tốn kém.
Đó là lý do tại sao rất nhiều công ty không làm điều đó.
Và họ sẽ thỏa hiệp và chỉ đi với ba và bốn.
Vì vậy, họ sẽ chỉ thực hiện một thử nghiệm vá lỗi và có một chương trình tiền thưởng lỗi.
Và sau đó các công ty khác đôi khi còn thỏa hiệp nhiều hơn nữa.
Và chọn một trong hai hoặc thực hiện chương trình tiền thưởng lỗi hoặc kiểm tra bút.
Theo tôi, một bài kiểm tra bằng bút không phải là một sự thay thế cho một chương trình tiền thưởng lỗi và ngược lại.
Tôi khuyên bạn nên làm cả hai vì, như tôi đã nói, mỗi cái đều có ưu điểm và nhược
điểm của nó.
Nhưng nếu bạn thực sự không thể làm cả hai, thì ít nhất hãy làm một trong số chúng là mức tối thiểu.
Với tư cách là chủ sở hữu trang web hoặc chủ sở hữu ứng dụng, bạn chịu trách nhiệm về dữ liệu người dùng mà người
dùng đang tin tưởng bạn và do đó, bạn cần thực hiện ít nhất là cố gắng đảm bảo rằng dữ liệu
của họ được xử lý an toàn và bảo mật.