Kiểm tra bảo mật - Hướng dẫn nhanh
Kiểm tra bảo mật là rất quan trọng để giữ cho hệ thống được bảo vệ khỏi các hoạt động độc hại trên web.
Kiểm tra bảo mật là gì?
Kiểm tra bảo mật là một kỹ thuật kiểm tra để xác định xem hệ thống thông tin có bảo vệ dữ liệu và duy trì chức năng như dự kiến hay không. Kiểm tra bảo mật không đảm bảo an toàn hoàn toàn cho hệ thống, nhưng điều quan trọng là phải bao gồm kiểm tra bảo mật như một phần của quá trình kiểm tra.
Kiểm tra bảo mật thực hiện sáu biện pháp sau để cung cấp một môi trường an toàn -
Confidentiality - Nó bảo vệ chống lại việc tiết lộ thông tin cho người nhận ngoài ý muốn.
Integrity - Nó cho phép chuyển thông tin mong muốn chính xác và đúng đắn từ người gửi đến người nhận dự định.
Authentication - Nó xác minh và xác nhận danh tính của người dùng.
Authorization - Nó chỉ định quyền truy cập cho người dùng và tài nguyên.
Availability - Nó đảm bảo sự sẵn sàng của thông tin theo yêu cầu.
Non-repudiation - Nó đảm bảo không có sự từ chối từ người gửi hoặc người nhận về việc đã gửi hoặc nhận tin nhắn.
Thí dụ
Phát hiện một lỗ hổng bảo mật trong một ứng dụng dựa trên web bao gồm các bước phức tạp và tư duy sáng tạo. Đôi khi, một thử nghiệm đơn giản có thể gây ra rủi ro bảo mật nghiêm trọng nhất. Bạn có thể thử bài kiểm tra rất cơ bản này trên bất kỳ ứng dụng web nào -
Đăng nhập vào ứng dụng web bằng thông tin xác thực hợp lệ.
Đăng xuất khỏi ứng dụng web.
Nhấp vào nút QUAY LẠI của trình duyệt.
Xác minh xem bạn có được yêu cầu đăng nhập lại hay không hoặc bạn có thể quay lại trang đã đăng nhập một lần nữa hay không.
Kiểm tra bảo mật có thể được coi là một cuộc tấn công có kiểm soát vào hệ thống, nó phát hiện ra các lỗ hổng bảo mật một cách thực tế. Mục tiêu của nó là đánh giá tình trạng hiện tại của một hệ thống CNTT. Nó còn được gọi làpenetration test hoặc phổ biến hơn như ethical hacking.
Kiểm tra thâm nhập được thực hiện theo từng giai đoạn và ở đây trong chương này, chúng ta sẽ thảo luận về quá trình hoàn chỉnh. Tài liệu thích hợp nên được thực hiện trong mỗi giai đoạn để tất cả các bước cần thiết để tái tạo cuộc tấn công luôn sẵn sàng. Tài liệu cũng là cơ sở cho báo cáo chi tiết mà khách hàng nhận được khi kết thúc thử nghiệm thâm nhập.
Kiểm tra thâm nhập - Quy trình làm việc
Kiểm tra thâm nhập bao gồm bốn giai đoạn chính:
- In chân
- Scanning
- Enumeration
- Exploitation
Bốn bước này được lặp lại nhiều lần đi đôi với SDLC thông thường.
Phần mềm độc hại (phần mềm độc hại) là bất kỳ phần mềm nào cung cấp một phần toàn quyền kiểm soát hệ thống cho kẻ tấn công / người tạo phần mềm độc hại.
Phần mềm độc hại
Các dạng phần mềm độc hại khác nhau được liệt kê bên dưới -
Virus- Virus là một chương trình tạo ra các bản sao của chính nó và chèn các bản sao này vào các chương trình máy tính khác, tệp dữ liệu hoặc vào khu vực khởi động của đĩa cứng. Sau khi nhân bản thành công, vi-rút gây ra hoạt động có hại trên các máy chủ bị nhiễm như đánh cắp dung lượng đĩa cứng hoặc thời gian CPU.
Worm - Sâu là một loại phần mềm độc hại để lại một bản sao của chính nó trong bộ nhớ của mỗi máy tính trên đường dẫn của nó.
Trojan - Trojan là một loại phần mềm độc hại không tự sao chép có chứa mã độc hại, khi thực thi sẽ dẫn đến mất hoặc đánh cắp dữ liệu hoặc có thể gây hại cho hệ thống.
Adware- Phần mềm quảng cáo, còn được gọi là phần mềm miễn phí hoặc phần mềm quảng cáo chiêu hàng, là một phần mềm máy tính miễn phí có chứa các quảng cáo thương mại về trò chơi, thanh công cụ trên máy tính để bàn và các tiện ích. Nó là một ứng dụng dựa trên web và nó thu thập dữ liệu trình duyệt web để nhắm mục tiêu quảng cáo, đặc biệt là cửa sổ bật lên.
Spyware- Phần mềm gián điệp là phần mềm xâm nhập theo dõi ẩn danh người dùng, cho phép tin tặc lấy thông tin nhạy cảm từ máy tính của người dùng. Phần mềm gián điệp khai thác người dùng và các lỗ hổng ứng dụng thường được gắn vào các bản tải xuống phần mềm trực tuyến miễn phí hoặc các liên kết được người dùng nhấp vào.
Rootkit - Rootkit là phần mềm được tin tặc sử dụng để giành quyền truy cập cấp quản trị vào máy tính / mạng được cài đặt thông qua mật khẩu bị đánh cắp hoặc bằng cách khai thác lỗ hổng hệ thống mà nạn nhân không biết.
Biện pháp phòng ngừa
Các biện pháp sau có thể được thực hiện để tránh sự hiện diện của phần mềm độc hại trong hệ thống -
Đảm bảo hệ điều hành và các ứng dụng được cập nhật với các bản vá / cập nhật.
Không bao giờ mở những e-mail lạ, đặc biệt là những e-mail có tệp đính kèm.
Khi bạn tải xuống từ internet, hãy luôn kiểm tra những gì bạn cài đặt. Không chỉ cần nhấp vào OK để loại bỏ cửa sổ bật lên. Xác minh nhà xuất bản trước khi bạn cài đặt ứng dụng.
Cài đặt phần mềm diệt vi rút.
Đảm bảo bạn quét và cập nhật các chương trình chống vi-rút thường xuyên.
Cài đặt tường lửa.
Luôn bật và sử dụng các tính năng bảo mật do trình duyệt và ứng dụng cung cấp.
Phần mềm chống phần mềm độc hại
Phần mềm sau giúp xóa phần mềm độc hại khỏi hệ thống -
- Microsoft Security Essentials
- Microsoft Windows Defender
- AVG Internet Security
- Spybot - Tìm kiếm & tiêu diệt
- Avast! Home Edition để sử dụng cá nhân
- Panda Internet Security
- MacScan dành cho Mac OS và Mac OS X
Hiểu giao thức là rất quan trọng để nắm bắt tốt về kiểm tra bảo mật. Bạn sẽ có thể đánh giá cao tầm quan trọng của giao thức khi chúng tôi chặn dữ liệu gói giữa máy chủ web và máy khách.
Giao thức HTTP
Giao thức truyền siêu văn bản (HTTP) là một giao thức cấp ứng dụng dành cho các hệ thống thông tin siêu phương tiện phân tán, cộng tác. Đây là nền tảng cho giao tiếp dữ liệu cho World Wide Web từ năm 1990. HTTP là một giao thức chung và không trạng thái có thể được sử dụng cho các mục đích khác cũng như sử dụng phần mở rộng của các phương thức yêu cầu, mã lỗi và tiêu đề.
Về cơ bản, HTTP là một giao thức truyền thông dựa trên TCP / IP, được sử dụng để cung cấp dữ liệu như tệp HTML, tệp hình ảnh, kết quả truy vấn, v.v. qua web. Nó cung cấp một cách thức chuẩn hóa để các máy tính giao tiếp với nhau. Đặc tả HTTP chỉ định cách dữ liệu được yêu cầu của khách hàng được gửi đến máy chủ và cách máy chủ phản hồi những yêu cầu này.
Tính năng cơ bản
Có ba tính năng cơ bản sau đây làm cho HTTP trở thành một giao thức đơn giản nhưng mạnh mẽ -
HTTP is connectionless- Máy khách HTTP, tức là trình duyệt khởi tạo một yêu cầu HTTP. Sau khi đưa ra yêu cầu, máy khách ngắt kết nối với máy chủ và chờ phản hồi. Máy chủ xử lý yêu cầu và thiết lập lại kết nối với máy khách để gửi phản hồi trở lại.
HTTP is media independent- Bất kỳ loại dữ liệu nào cũng có thể được gửi bằng HTTP miễn là cả máy khách và máy chủ đều biết cách xử lý nội dung dữ liệu. Điều này là bắt buộc đối với máy khách cũng như máy chủ để chỉ định loại nội dung bằng kiểu MIME thích hợp.
HTTP is stateless- HTTP là một giao thức không có kết nối và đây là kết quả trực tiếp cho thấy HTTP là một giao thức không trạng thái. Máy chủ và máy khách chỉ biết về nhau khi có yêu cầu hiện tại. Sau đó, cả hai người đều quên nhau. Do tính chất này của giao thức, cả máy khách và trình duyệt đều không thể lưu giữ thông tin giữa các yêu cầu khác nhau trên các trang web.
HTTP / 1.0 sử dụng một kết nối mới cho mỗi trao đổi yêu cầu / phản hồi trong khi kết nối HTTP / 1.1 có thể được sử dụng cho một hoặc nhiều trao đổi yêu cầu / phản hồi.
Ngành kiến trúc
Sơ đồ sau đây cho thấy một kiến trúc rất cơ bản của một ứng dụng web và mô tả vị trí của HTTP:
Giao thức HTTP là một giao thức yêu cầu / phản hồi dựa trên kiến trúc máy khách / máy chủ nơi trình duyệt web, rô bốt và công cụ tìm kiếm, v.v. hoạt động như máy khách HTTP và máy chủ web hoạt động như một máy chủ.
Client - Máy khách HTTP gửi một yêu cầu đến máy chủ dưới dạng phương thức yêu cầu, URI và phiên bản giao thức, sau đó là một thông báo giống MIME chứa các công cụ sửa đổi yêu cầu, thông tin máy khách và nội dung cơ thể có thể có qua kết nối TCP / IP.
Server - Máy chủ HTTP phản hồi bằng dòng trạng thái, bao gồm phiên bản giao thức của thông báo và mã thành công hoặc lỗi, theo sau là thông báo giống MIME chứa thông tin máy chủ, thông tin meta thực thể và nội dung phần thể thực thể có thể có.
HTTP - Nhược điểm
HTTP không phải là một giao thức được bảo mật hoàn toàn.
HTTP sử dụng cổng 80 làm cổng mặc định để giao tiếp.
HTTP hoạt động ở Lớp ứng dụng. Nó cần tạo nhiều kết nối để truyền dữ liệu, điều này làm tăng chi phí quản lý.
Không cần mã hóa / chứng chỉ kỹ thuật số để sử dụng HTTP.
Chi tiết giao thức Http
Để hiểu sâu về Giao thức HTTP, hãy nhấp vào từng liên kết bên dưới.
HTTP Parameters
HTTP Messages
HTTP Requests
HTTP Responses
HTTP Methods
HTTP Status Codes
HTTP Header Fields
HTTP Security
HTTPS (Giao thức truyền siêu văn bản qua Lớp cổng bảo mật) hoặc HTTP qua SSL là một giao thức web được phát triển bởi Netscape. Nó không phải là một giao thức mà nó chỉ là kết quả của việc xếp lớp HTTP lên trên SSL / TLS (Secure Socket Layer / Transport Layer Security).
Tóm lại, HTTPS = HTTP + SSL
Khi nào là bắt buộc sử dụng HTTPS?
Khi chúng tôi duyệt, chúng tôi thường gửi và nhận thông tin bằng giao thức HTTP. Vì vậy, điều này dẫn đến việc bất kỳ ai cũng có thể nghe trộm cuộc trò chuyện giữa máy tính của chúng ta và máy chủ web. Nhiều khi chúng ta cần trao đổi thông tin nhạy cảm cần được bảo mật và ngăn chặn truy cập trái phép.
Giao thức Https được sử dụng trong các trường hợp sau:
- Trang web ngân hàng
- Cổng thanh toán
- Trang web mua sắm
- Tất cả các trang đăng nhập
- Ứng dụng email
Hoạt động cơ bản của HTTPS
Khóa công khai và chứng chỉ đã ký là bắt buộc đối với máy chủ trong Giao thức HTTPS.
Khách hàng yêu cầu trang https: //
Khi sử dụng kết nối https, máy chủ phản hồi kết nối ban đầu bằng cách đưa ra danh sách các phương pháp mã hóa mà máy chủ web hỗ trợ.
Đáp lại, máy khách chọn một phương thức kết nối, máy khách và máy chủ trao đổi chứng chỉ để xác thực danh tính của họ.
Sau khi thực hiện xong, cả máy chủ web và máy khách đều trao đổi thông tin được mã hóa sau khi đảm bảo rằng cả hai đều đang sử dụng cùng một khóa và kết nối được đóng.
Để lưu trữ các kết nối https, máy chủ phải có chứng chỉ khóa công khai, chứng chỉ này nhúng thông tin khóa với xác minh danh tính của chủ sở hữu khóa.
Hầu hết tất cả các chứng chỉ đều được xác minh bởi bên thứ ba để khách hàng yên tâm rằng khóa luôn được bảo mật.
Mã hóa và Giải mã là gì?
Mã hóa là quá trình đưa một chuỗi các ký tự như chữ cái, số và các ký tự đặc biệt khác vào một định dạng chuyên biệt để truyền tải hiệu quả.
Giải mã là quá trình chuyển đổi một định dạng được mã hóa trở lại chuỗi ký tự ban đầu. Nó hoàn toàn khác với Mã hóa mà chúng ta thường hiểu sai.
Mã hóa và giải mã được sử dụng trong truyền thông và lưu trữ dữ liệu. Mã hóa KHÔNG được sử dụng để vận chuyển thông tin nhạy cảm.
Mã hóa URL
URL chỉ có thể được gửi qua Internet bằng cách sử dụng bộ ký tự ASCII và có những trường hợp URL chứa các ký tự đặc biệt ngoài các ký tự ASCII, nó cần được mã hóa. URL không chứa khoảng trắng và được thay thế bằng dấu cộng (+) hoặc bằng% 20.
Mã hóa ASCII
Trình duyệt (phía máy khách) sẽ mã hóa đầu vào theo bộ ký tự được sử dụng trong trang web và bộ ký tự mặc định trong HTML5 là UTF-8.
Bảng sau hiển thị biểu tượng ASCII của ký tự và Biểu tượng bằng nhau của nó và cuối cùng là biểu tượng thay thế có thể được sử dụng trong URL trước khi chuyển nó đến máy chủ -
ASCII | Biểu tượng | Sự thay thế |
---|---|---|
<32 | Mã hóa với% xx trong đó xx là đại diện thập lục phân của ký tự. | |
32 | không gian | + hoặc% 20 |
33 | ! | % 21 |
34 | " | % 22 |
35 | # | % 23 |
36 | $ | % 24 |
37 | % | % 25 |
38 | & | % 26 |
39 | ' | % 27 |
40 | ( | % 28 |
41 | ) | % 29 |
42 | * | * |
43 | + | % 2B |
44 | , | % 2C |
45 | - | - |
46 | . | . |
47 | / | % 2F |
48 | 0 | 0 |
49 | 1 | 1 |
50 | 2 | 2 |
51 | 3 | 3 |
52 | 4 | 4 |
53 | 5 | 5 |
54 | 6 | 6 |
55 | 7 | 7 |
56 | số 8 | số 8 |
57 | 9 | 9 |
58 | : | % 3A |
59 | ; | % 3B |
60 | > | % 3C |
61 | = | % 3D |
62 | > | % 3E |
63 | ? | % 3F |
64 | @ | % 40 |
65 | A | A |
66 | B | B |
67 | C | C |
68 | D | D |
69 | E | E |
70 | F | F |
71 | G | G |
72 | H | H |
73 | Tôi | Tôi |
74 | J | J |
75 | K | K |
76 | L | L |
77 | M | M |
78 | N | N |
79 | O | O |
80 | P | P |
81 | Q | Q |
82 | R | R |
83 | S | S |
84 | T | T |
85 | U | U |
86 | V | V |
87 | W | W |
88 | X | X |
89 | Y | Y |
90 | Z | Z |
91 | [ | % 5B |
92 | \ | % 5C |
93 | ] | % 5D |
94 | ^ | % 5E |
95 | _ | _ |
96 | ` | % 60 |
97 | a | a |
98 | b | b |
99 | c | c |
100 | d | d |
101 | e | e |
102 | f | f |
103 | g | g |
104 | h | h |
105 | Tôi | Tôi |
106 | j | j |
107 | k | k |
108 | l | l |
109 | m | m |
110 | n | n |
111 | o | o |
112 | p | p |
113 | q | q |
114 | r | r |
115 | S | S |
116 | t | t |
117 | u | u |
118 | v | v |
119 | w | w |
120 | x | x |
121 | y | y |
122 | z | z |
123 | { | % 7B |
124 | | | % 7C |
125 | } | % 7D |
126 | ~ | % 7E |
127 | % 7F | |
> 127 | Mã hóa với% xx trong đó xx là đại diện thập lục phân của ký tự |
Mật mã là gì?
Mật mã học là khoa học để mã hóa và giải mã dữ liệu cho phép người dùng lưu trữ thông tin nhạy cảm hoặc truyền thông tin đó qua các mạng không an toàn để chỉ người nhận dự định mới có thể đọc được.
Dữ liệu có thể được đọc và hiểu mà không cần bất kỳ biện pháp đặc biệt nào được gọi là plaintext, trong khi phương pháp ngụy trang bản rõ để che giấu bản chất của nó được gọi là encryption.
Bản rõ được mã hóa được gọi là văn bản mật mã và quá trình hoàn nguyên dữ liệu đã mã hóa trở lại văn bản thuần túy được gọi là decryption.
Khoa học phân tích và phá vỡ thông tin liên lạc an toàn được gọi là phân tích mật mã. Những người thực hiện tương tự còn được gọi là kẻ tấn công.
Mật mã có thể mạnh hoặc yếu và độ mạnh được đo bằng thời gian và nguồn lực mà nó cần để khôi phục bản rõ thực tế.
Do đó, cần có một công cụ giải mã thích hợp để giải mã các thông điệp được mã hóa mạnh.
Có một số kỹ thuật mật mã có sẵn mà ngay cả một tỷ máy tính thực hiện một tỷ lần kiểm tra một giây, cũng không thể giải mã được văn bản.
Khi sức mạnh tính toán đang tăng lên từng ngày, người ta phải tạo ra các thuật toán mã hóa rất mạnh để bảo vệ dữ liệu và thông tin quan trọng khỏi những kẻ tấn công.
Mã hóa hoạt động như thế nào?
Thuật toán mật mã hoạt động kết hợp với một khóa (có thể là một từ, số hoặc cụm từ) để mã hóa bản rõ và cùng một bản rõ mã hóa thành văn bản mật mã khác nhau với các khóa khác nhau.
Do đó, dữ liệu được mã hóa hoàn toàn phụ thuộc vào một số tham số như độ mạnh của thuật toán mật mã và tính bí mật của khóa.
Kỹ thuật mật mã
Symmetric Encryption- Mật mã thông thường, còn được gọi là mã hóa thông thường, là kỹ thuật trong đó chỉ một khóa được sử dụng cho cả mã hóa và giải mã. Ví dụ, các thuật toán DES, Triple DES, MARS của IBM, RC2, RC4, RC5, RC6.
Asymmetric Encryption- Đây là mật mã khóa công khai sử dụng một cặp khóa để mã hóa: khóa công khai để mã hóa dữ liệu và khóa riêng để giải mã. Khóa công khai được công bố cho mọi người trong khi vẫn giữ bí mật khóa riêng tư. Ví dụ, RSA, Thuật toán chữ ký số (DSA), Elgamal.
Hashing- Hashing là mã hóa MỘT CHIỀU, tạo ra đầu ra bị xáo trộn không thể đảo ngược hoặc ít nhất là không thể đảo ngược dễ dàng. Ví dụ, thuật toán MD5. Nó được sử dụng để tạo Chứng chỉ kỹ thuật số, Chữ ký điện tử, Lưu trữ mật khẩu, Xác minh thông tin liên lạc, v.v.
Chính sách nguồn gốc giống nhau (SOP) là một khái niệm quan trọng trong mô hình bảo mật ứng dụng web.
Chính sách Xuất xứ Giống nhau là gì?
Theo chính sách này, nó cho phép các tập lệnh chạy trên các trang có nguồn gốc từ cùng một trang web có thể là sự kết hợp của những điều sau:
- Domain
- Protocol
- Port
Thí dụ
Lý do đằng sau hành vi này là bảo mật. Nếu bạn có try.com trong một cửa sổ và gmail.com trong cửa sổ khác, thì bạn KHÔNG muốn một tập lệnh từ try.com truy cập hoặc sửa đổi nội dung của gmail.com hoặc thực hiện các hành động trong ngữ cảnh của gmail thay cho bạn.
Dưới đây là các trang web từ cùng một nguồn gốc. Như đã giải thích trước đây, nguồn gốc giống nhau sẽ xem xét miền / giao thức / cổng.
- http://website.com
- http://website.com/
- http://website.com/my/contact.html
Dưới đây là các trang web từ một nguồn khác.
- http://www.site.co.uk (miền khác)
- http://site.org (miền khác)
- https://site.com (một giao thức khác)
- http://site.com:8080 (cổng khác)
Chính sách xuất xứ giống nhau Ngoại lệ cho IE
Internet Explorer có hai ngoại lệ chính đối với SOP.
Cái đầu tiên liên quan đến 'Vùng đáng tin cậy'. Nếu cả hai miền đều nằm trong vùng đáng tin cậy thì chính sách Nguồn gốc giống nhau hoàn toàn không được áp dụng.
Ngoại lệ thứ hai trong IE liên quan đến cổng. IE không đưa vào chính sách Nguồn gốc giống nhau, do đó http://website.com và http://wesite.com:4444 được coi là có cùng nguồn gốc và không có hạn chế nào được áp dụng.
Cookie là gì?
Cookie là một mẩu thông tin nhỏ được gửi bởi máy chủ web để lưu trữ trên trình duyệt web để sau này trình duyệt có thể đọc được. Bằng cách này, trình duyệt ghi nhớ một số thông tin cá nhân cụ thể. Nếu một Hacker nắm được thông tin cookie, nó có thể dẫn đến các vấn đề bảo mật.
Thuộc tính của Cookie
Dưới đây là một số thuộc tính quan trọng của cookie -
Chúng thường là các tệp văn bản nhỏ, có thẻ ID được lưu trữ trên thư mục trình duyệt của máy tính của bạn.
Chúng được các nhà phát triển web sử dụng để giúp người dùng điều hướng trang web của họ một cách hiệu quả và thực hiện các chức năng nhất định.
Khi người dùng duyệt lại cùng một trang web, dữ liệu được lưu trữ trong cookie sẽ được gửi trở lại máy chủ web để thông báo cho trang web về các hoạt động trước đó của người dùng.
Cookie là không thể tránh khỏi đối với các trang web có cơ sở dữ liệu khổng lồ, cần đăng nhập, có chủ đề tùy biến.
Nội dung cookie
Cookie chứa thông tin sau:
- Tên của máy chủ mà cookie được gửi từ đó.
- Thời gian tồn tại của cookie.
- Một giá trị - thường là một số duy nhất được tạo ngẫu nhiên.
Các loại bánh quy
Session Cookies- Các cookie này là tạm thời sẽ bị xóa khi người dùng đóng trình duyệt. Ngay cả khi người dùng đăng nhập lại, một cookie mới cho phiên đó sẽ được tạo.
Persistent cookies- Các cookie này vẫn còn trên ổ đĩa cứng trừ khi người dùng xóa chúng đi hoặc chúng hết hạn. Thời hạn sử dụng của Cookie phụ thuộc vào việc chúng có thể tồn tại trong bao lâu.
Kiểm tra Cookie
Dưới đây là các cách để kiểm tra cookie -
Disabling Cookies- Với tư cách là người kiểm tra, chúng tôi cần xác minh quyền truy cập của trang web sau khi tắt cookie và kiểm tra xem các trang có hoạt động bình thường hay không. Điều hướng đến tất cả các trang của trang web và xem các lỗi ứng dụng. Nó cũng được yêu cầu thông báo cho người dùng rằng cookie được yêu cầu để sử dụng trang web.
Corrupting Cookies- Một thử nghiệm khác sẽ được thực hiện là làm hỏng cookie. Để làm điều tương tự, người ta phải tìm vị trí của cookie của trang web và chỉnh sửa thủ công nó với dữ liệu giả mạo / không hợp lệ có thể được sử dụng để truy cập thông tin nội bộ từ tên miền mà sau đó có thể được sử dụng để hack trang web.
Removing Cookies - Gỡ bỏ tất cả các cookie cho trang web và kiểm tra cách trang web phản ứng với nó.
Cross-Browser Compatibility - Điều quan trọng nữa là kiểm tra xem cookie có được viết đúng trên tất cả các trình duyệt được hỗ trợ từ bất kỳ trang nào viết cookie hay không.
Editing Cookies- Nếu ứng dụng sử dụng cookie để lưu trữ thông tin đăng nhập thì với tư cách là người kiểm tra, chúng tôi nên thử thay đổi người dùng trong cookie hoặc thanh địa chỉ thành một người dùng hợp lệ khác. Việc chỉnh sửa cookie sẽ không cho phép bạn đăng nhập vào tài khoản người dùng khác.
Xem và Chỉnh sửa Cookie
Các trình duyệt hiện đại hỗ trợ xem / chỉnh sửa cookie thông báo trong chính Trình duyệt. Có các plugin cho mozilla / chrome mà chúng tôi có thể thực hiện chỉnh sửa thành công.
- Chỉnh sửa plugin cookie cho Firefox
- Chỉnh sửa plugin cookie này cho chrome
Các bước cần được thực hiện để Chỉnh sửa cookie -
Tải xuống plugin cho Chrome từ đây
Chỉnh sửa giá trị cookie chỉ bằng cách truy cập vào plugin 'chỉnh sửa cookie này' từ chrome như được hiển thị bên dưới.
Có nhiều phương pháp / phương pháp tiếp cận khác nhau mà chúng tôi có thể sử dụng làm tài liệu tham khảo để thực hiện một cuộc tấn công.
Ứng dụng Web - Phương pháp PenT Testing
Người ta có thể tính đến các tiêu chuẩn sau trong khi phát triển mô hình tấn công.
Trong số danh sách sau, OWASP là hoạt động tích cực nhất và có một số người đóng góp. Chúng tôi sẽ tập trung vào Kỹ thuật OWASP mà mỗi nhóm phát triển sẽ cân nhắc trước khi thiết kế ứng dụng web.
PTES - Tiêu chuẩn thực thi kiểm tra thâm nhập
OSSTMM - Sổ tay Phương pháp Kiểm tra Bảo mật Nguồn Mở
Kỹ thuật kiểm tra OWASP - Giao thức bảo mật ứng dụng web mở
OWASP Top 10
Nhóm Giao thức bảo mật ứng dụng web mở đã đưa ra 10 lỗ hổng hàng đầu phổ biến hơn trên web trong những năm gần đây. Dưới đây là danh sách các lỗi bảo mật phổ biến hơn trong một ứng dụng dựa trên web.
Ứng dụng - Thực hành
Để hiểu từng kỹ thuật, chúng ta hãy làm việc với một ứng dụng mẫu. Chúng tôi sẽ thực hiện cuộc tấn công vào 'WebGoat', ứng dụng J2EE được phát triển rõ ràng với các lỗi bảo mật cho mục đích học tập.
Thông tin chi tiết đầy đủ về dự án webgoat có thể được tìm thấy https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. Để tải xuống ứng dụng WebGoat, hãy điều hướng đếnhttps://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) và goto phần tải xuống.
Để cài đặt ứng dụng đã tải xuống, trước tiên hãy đảm bảo rằng bạn không có bất kỳ ứng dụng nào chạy trên Cổng 8080. Bạn có thể cài đặt ứng dụng này chỉ bằng một lệnh duy nhất - java -jar WebGoat-6.0.1-war-execute.jar. Để biết thêm chi tiết, hãy truy cập Cài đặt WebGoat
Đăng Cài đặt, chúng tôi sẽ có thể truy cập ứng dụng bằng cách điều hướng đến http://localhost:8080/WebGoat/attack và trang sẽ được hiển thị như hình dưới đây.
Chúng tôi có thể sử dụng thông tin đăng nhập của khách hoặc quản trị viên như được hiển thị trong trang đăng nhập.
Mạng đại diện
Để chặn lưu lượng giữa máy khách (Trình duyệt) và Máy chủ (Hệ thống lưu trữ Ứng dụng Webgoat trong trường hợp của chúng tôi), chúng tôi cần sử dụng proxy web. Chúng tôi sẽ sử dụng Burp Proxy có thể được tải xuống từhttps://portswigger.net/burp/download.html
Chỉ cần bạn tải xuống phiên bản miễn phí của burp suite như hình dưới đây là đủ.
Cấu hình Burp Suite
Burp Suite là một proxy web có thể chặn từng gói thông tin được gửi và nhận bởi trình duyệt và máy chủ web. Điều này giúp chúng tôi sửa đổi nội dung trước khi máy khách gửi thông tin đến Máy chủ Web.
Step 1- Ứng dụng được cài đặt trên cổng 8080 và Burp được cài đặt trên cổng 8181 như hình dưới đây. Khởi chạy bộ Burp và thực hiện các cài đặt sau để kích hoạt nó trong cổng 8181 như hình dưới đây.
Step 2- Chúng ta nên đảm bảo rằng Burp đang lắng nghe Cổng # 8080 nơi ứng dụng được cài đặt để bộ Burp có thể chặn lưu lượng. Cài đặt này nên được thực hiện trên tab phạm vi của Burp Suite như hình dưới đây.
Step 3- Sau đó thực hiện cài đặt proxy trình duyệt của bạn để lắng nghe cổng 8181 (cổng Burp Suite). Vì vậy, chúng tôi đã cấu hình proxy Web để chặn lưu lượng giữa máy khách (trình duyệt) và máy chủ (Máy chủ web) như hình dưới đây:
Step 4 - Ảnh chụp nhanh của cấu hình được hiển thị bên dưới với sự trợ giúp của một sơ đồ quy trình làm việc đơn giản như hình dưới đây
Kỹ thuật tiêm bao gồm việc đưa vào một truy vấn SQL hoặc một lệnh sử dụng các trường đầu vào của ứng dụng.
Ứng dụng web - Tiêm
Một SQL injection thành công có thể đọc, sửa đổi dữ liệu nhạy cảm từ cơ sở dữ liệu và cũng có thể xóa dữ liệu khỏi cơ sở dữ liệu. Nó cũng cho phép hacker thực hiện các hoạt động quản trị trên cơ sở dữ liệu như tắt DBMS / hủy bỏ cơ sở dữ liệu.
Hãy cho chúng tôi hiểu Tác nhân đe dọa, Vectơ tấn công, Điểm yếu về bảo mật, Tác động kỹ thuật và Tác động kinh doanh của lỗ hổng này với sự trợ giúp của sơ đồ đơn giản.
Ví dụ
Ứng dụng sử dụng dữ liệu không đáng tin cậy trong việc xây dựng lệnh gọi SQL dễ bị tấn công sau:
String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";
Thực hành
Step 1 - Điều hướng đến vùng SQL Injection của ứng dụng như hình dưới đây.
Step 2- Như đã đưa ra trong bài tập, chúng ta sử dụng String SQL Injection để bỏ qua xác thực. Sử dụng SQL injection để đăng nhập với tư cách là ông chủ ('Neville') mà không cần sử dụng mật khẩu chính xác. Xác minh rằng hồ sơ của Neville có thể được xem và tất cả các chức năng đều có sẵn (bao gồm Tìm kiếm, Tạo và Xóa).
Step 3 - Chúng tôi sẽ chèn một SQL để chúng tôi có thể bỏ qua mật khẩu bằng cách gửi tham số là 'a' = 'a' hoặc 1 = 1
Step 4 - Đăng Khai thác, chúng ta có thể đăng nhập Neville là Admin như hình bên dưới.
Ngăn chặn SQL Injection
Có rất nhiều cách để ngăn chặn SQL injection. Khi các nhà phát triển viết mã, họ nên đảm bảo rằng họ xử lý các ký tự đặc biệt cho phù hợp. Có sẵn các bảng / kỹ thuật phòng chống gian lận từ OWASP, đây chắc chắn là hướng dẫn cho các nhà phát triển.
- Sử dụng các truy vấn được tham số hóa
- Thoát tất cả thông tin đầu vào do người dùng cung cấp
- Bật Đặc quyền Ít nhất cho cơ sở dữ liệu cho người dùng cuối
Khi các chức năng xác thực liên quan đến ứng dụng không được triển khai đúng cách, nó cho phép tin tặc xâm phạm mật khẩu hoặc ID phiên hoặc khai thác các lỗ hổng triển khai khác bằng thông tin đăng nhập của người dùng khác.
Hãy cho chúng tôi hiểu Tác nhân đe dọa, Vectơ tấn công, Điểm yếu về bảo mật, Tác động kỹ thuật và Tác động kinh doanh của lỗ hổng này với sự trợ giúp của sơ đồ đơn giản.
Thí dụ
An e-commerce application supports URL rewriting, putting session IDs in the URL −
http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop
Người dùng được xác thực của trang web sẽ chuyển tiếp URL cho bạn bè của họ để biết về việc giảm giá. Anh ta gửi email liên kết trên mà không biết rằng người dùng cũng đang cung cấp ID phiên. Khi bạn bè của anh ấy sử dụng liên kết, họ sử dụng phiên và thẻ tín dụng của anh ấy.
BẬT tay
Step 1- Đăng nhập vào Webgoat và điều hướng đến Phần 'Quy tắc quản lý phiên'. Hãy để chúng tôi vượt qua xác thực bằng cách giả mạo cookie. Dưới đây là ảnh chụp nhanh của kịch bản.
Step 2 - Khi chúng tôi đăng nhập bằng thông tin xác thực webgoat / webgoat, chúng tôi nhận thấy từ Burp Suite rằng ID JSESSION là C8F3177CCAFF380441ABF71090748F2E trong khi AuthCookie = 65432ubphcfx khi xác thực thành công.
Step 3 - Khi chúng tôi đăng nhập bằng khía cạnh / khía cạnh thông tin xác thực, chúng tôi thấy từ Burp Suite rằng ID JSESSION là C8F3177CCAFF380441ABF71090748F2E trong khi AuthCookie = 65432udfqtb khi xác thực thành công.
Step 4- Bây giờ chúng ta cần phân tích các mẫu AuthCookie. Nửa đầu '65432' là chung cho cả hai lần xác thực. Do đó, chúng tôi hiện đang quan tâm đến việc phân tích phần cuối cùng của các giá trị authcookie như - ubphcfx cho người dùng webgoat và udfqtb cho người dùng khía cạnh tương ứng.
Step 5- Nếu chúng ta xem xét kỹ các giá trị AuthCookie, phần cuối cùng có cùng độ dài với độ dài của tên người dùng. Do đó, rõ ràng là tên người dùng được sử dụng với một số phương pháp mã hóa. Sau khi dùng thử và các cơ chế lỗi / brute force, chúng tôi thấy rằng sau khi đảo ngược tên người dùng, webgoat; chúng ta kết thúc bằng taogbew và sau đó ký tự trước bảng chữ cái là ký tự được sử dụng làm AuthCookie. tức là ubphcfx.
Step 6- Nếu chúng tôi chuyển giá trị cookie này và cho chúng tôi xem điều gì sẽ xảy ra. Sau khi xác thực là webgoat của người dùng, hãy thay đổi giá trị AuthCookie để chế nhạo người dùng Alice bằng cách tìm AuthCookie cho giống nhau bằng cách thực hiện bước # 4 và bước # 5.
Cơ chế ngăn chặn
Phát triển kiểm soát xác thực và quản lý phiên mạnh mẽ để đáp ứng tất cả các yêu cầu xác thực và quản lý phiên được xác định trong Tiêu chuẩn xác minh bảo mật ứng dụng của OWASP.
Các nhà phát triển nên đảm bảo rằng họ tránh được các lỗi XSS có thể được sử dụng để lấy cắp các ID phiên.
Cross-site Scripting (XSS) xảy ra bất cứ khi nào ứng dụng lấy dữ liệu không đáng tin cậy và gửi đến máy khách (trình duyệt) mà không được xác thực. Điều này cho phép những kẻ tấn công thực thi các tập lệnh độc hại trong trình duyệt của nạn nhân, điều này có thể dẫn đến việc chiếm quyền điều khiển phiên người dùng, phá hoại các trang web hoặc chuyển hướng người dùng đến các trang web độc hại.
Hãy cho chúng tôi hiểu Tác nhân đe dọa, Vectơ tấn công, Điểm yếu về bảo mật, Tác động kỹ thuật và Tác động kinh doanh của lỗ hổng này với sự trợ giúp của sơ đồ đơn giản.
Các loại XSS
Stored XSS - XSS được lưu trữ còn được gọi là XSS liên tục xảy ra khi đầu vào của người dùng được lưu trữ trên máy chủ đích như cơ sở dữ liệu / diễn đàn tin nhắn / trường bình luận, v.v. Sau đó, nạn nhân có thể lấy dữ liệu đã lưu trữ từ ứng dụng web.
Reflected XSS - XSS phản ánh còn được gọi là XSS không liên tục xảy ra khi thông tin nhập của người dùng được ứng dụng web trả về ngay lập tức trong thông báo lỗi / kết quả tìm kiếm hoặc thông tin đầu vào do người dùng cung cấp như một phần của yêu cầu và không lưu trữ vĩnh viễn dữ liệu do người dùng cung cấp.
DOM Based XSS - DOM Based XSS là một dạng XSS khi nguồn dữ liệu nằm trong DOM, phần chìm cũng nằm trong DOM và luồng dữ liệu không bao giờ rời khỏi trình duyệt.
Thí dụ
Ứng dụng sử dụng dữ liệu không đáng tin cậy trong việc xây dựng mà không được xác nhận. Các ký tự đặc biệt phải được thoát.
http://www.webpage.org/task/Rule1?query=try
Kẻ tấn công sửa đổi tham số truy vấn trong trình duyệt của họ thành -
http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>
BẬT tay
Step 1- Đăng nhập vào Webgoat và điều hướng đến Phần tạo script trên nhiều trang (XSS). Hãy để chúng tôi thực hiện một cuộc tấn công Stored Cross-site Scripting (XSS). Dưới đây là ảnh chụp nhanh của kịch bản.
Step 2- Theo kịch bản, chúng ta hãy đăng nhập với tên Tom với mật khẩu 'tom' như đã đề cập trong chính kịch bản. Nhấp vào 'xem hồ sơ' và vào chế độ chỉnh sửa. Vì tom là kẻ tấn công, chúng ta hãy đưa tập lệnh Java vào các hộp chỉnh sửa đó.
<script>
alert("HACKED")
</script>
Step 3 - Ngay sau khi cập nhật kết thúc, tom nhận được một hộp cảnh báo với thông báo "bị tấn công" có nghĩa là ứng dụng đang bị tấn công.
Step 4 - Bây giờ theo kịch bản, chúng ta cần đăng nhập bằng jerry (HR) và kiểm tra xem jerry có bị ảnh hưởng bởi tập lệnh được chèn hay không.
Step 5 - Sau khi đăng nhập với tư cách Jerry, bạn chọn 'Tom' và bấm vào 'xem hồ sơ' như hình bên dưới.
Trong khi xem hồ sơ của tom từ tài khoản của Jerry, anh ấy có thể nhận được hộp thông báo tương tự.
Step 6 - Hộp thông báo này chỉ là một ví dụ, nhưng kẻ tấn công thực sự có thể thực hiện nhiều hơn là chỉ hiển thị một hộp thông báo.
Cơ chế phòng ngừa
Các nhà phát triển phải đảm bảo rằng họ thoát khỏi tất cả dữ liệu không đáng tin cậy dựa trên ngữ cảnh HTML như nội dung, thuộc tính, JavaScript, CSS hoặc URL mà dữ liệu được đặt vào.
Đối với những ứng dụng cần các ký tự đặc biệt làm đầu vào, cần có các cơ chế xác nhận mạnh mẽ trước khi chấp nhận chúng làm đầu vào hợp lệ.
Tham chiếu đối tượng trực tiếp có khả năng xảy ra khi nhà phát triển để lộ tham chiếu đến đối tượng triển khai nội bộ, chẳng hạn như tệp, thư mục hoặc khóa cơ sở dữ liệu mà không có bất kỳ cơ chế xác thực nào cho phép kẻ tấn công thao túng các tham chiếu này để truy cập dữ liệu trái phép.
Hãy cho chúng tôi hiểu Tác nhân đe dọa, Vectơ tấn công, Điểm yếu về bảo mật, Tác động kỹ thuật và Tác động kinh doanh của lỗ hổng này với sự trợ giúp của sơ đồ đơn giản.
Thí dụ
Ứng dụng sử dụng dữ liệu chưa được xác minh trong lệnh gọi SQL đang truy cập thông tin tài khoản.
String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );
Kẻ tấn công sửa đổi tham số truy vấn trong trình duyệt của họ để trỏ đến Admin.
http://webapp.com/app/accountInfo?acct=admin
BẬT tay
Step 1- Đăng nhập vào Webgoat và điều hướng đến Phần kiểm soát lỗi truy cập. Mục đích là để truy xuất tomcat-users.xml bằng cách điều hướng đến đường dẫn nơi nó nằm. Dưới đây là ảnh chụp nhanh của kịch bản.
Step 2 - Đường dẫn của tệp được hiển thị trong trường 'thư mục hiện tại là' - C: \ Users \ userName $ \. Extract \ webapps \ WebGoat \ lesson_plans \ en và chúng tôi cũng biết rằng tệp tomcat-users.xml được giữ trong C: \ xampp \ tomcat \ conf
Step 3- Chúng ta cần đi qua tất cả các cách ra khỏi thư mục hiện tại và điều hướng từ C: \ Drive. Chúng tôi có thể thực hiện tương tự bằng cách chặn lưu lượng truy cập bằng Burp Suite.
Step 4 - Nếu thành công, nó sẽ hiển thị tomcat-users.xml với thông báo "Xin chúc mừng. Bạn đã hoàn thành bài học này thành công."
Cơ chế phòng ngừa
Các nhà phát triển có thể sử dụng các tài nguyên / điểm sau làm hướng dẫn để ngăn chặn tham chiếu đối tượng trực tiếp không an toàn trong chính giai đoạn phát triển.
Các nhà phát triển chỉ nên sử dụng một người dùng hoặc phiên cho các tham chiếu đối tượng gián tiếp.
Bạn cũng nên kiểm tra quyền truy cập trước khi sử dụng tham chiếu đối tượng trực tiếp từ một nguồn không đáng tin cậy.
Cấu hình sai bảo mật phát sinh khi cài đặt Bảo mật được xác định, triển khai và duy trì dưới dạng mặc định. Bảo mật tốt yêu cầu một cấu hình an toàn được xác định và triển khai cho ứng dụng, máy chủ web, máy chủ cơ sở dữ liệu và nền tảng. Điều quan trọng không kém là phải cập nhật phần mềm.
Thí dụ
Một số ví dụ cổ điển về cấu hình sai bảo mật như đã cho:
Nếu danh sách Thư mục không bị vô hiệu hóa trên máy chủ và nếu kẻ tấn công phát hiện ra điều tương tự thì kẻ tấn công có thể chỉ cần liệt kê các thư mục để tìm bất kỳ tệp nào và thực thi nó. Cũng có thể lấy cơ sở mã thực tế chứa tất cả mã tùy chỉnh của bạn và sau đó tìm ra lỗi nghiêm trọng trong ứng dụng.
Cấu hình máy chủ ứng dụng cho phép trả lại dấu vết ngăn xếp cho người dùng, có khả năng làm lộ các lỗi cơ bản. Những kẻ tấn công lấy những thông tin bổ sung mà thông báo lỗi cung cấp đủ để chúng xâm nhập.
Máy chủ ứng dụng thường đi kèm với các ứng dụng mẫu không được bảo mật tốt. Nếu không được xóa khỏi máy chủ sản xuất sẽ dẫn đến ảnh hưởng đến máy chủ của bạn.
BẬT tay
Step 1- Khởi chạy Webgoat và điều hướng đến phần cấu hình không an toàn và để chúng tôi giải quyết thử thách đó. Ảnh chụp tương tự được cung cấp bên dưới -
Step 2- Chúng tôi có thể thử nhiều tùy chọn nhất có thể. Tất cả những gì chúng ta cần để tìm URL của tệp cấu hình và chúng tôi biết rằng các nhà phát triển tuân theo loại quy ước đặt tên cho tệp cấu hình. Nó có thể là bất cứ thứ gì được liệt kê dưới đây. Nó thường được thực hiện bằng kỹ thuật lực BRUTE.
- web.config
- config
- appname.config
- conf
Step 3 - Sau khi thử các tùy chọn khác nhau, chúng tôi thấy rằng 'http://localhost:8080/WebGoat/conf' là thành công. Trang sau được hiển thị nếu thử thành công -
Cơ chế phòng ngừa
Tất cả các môi trường như Môi trường phát triển, QA và sản xuất phải được cấu hình giống hệt nhau bằng cách sử dụng các mật khẩu khác nhau được sử dụng trong mỗi môi trường mà không thể dễ dàng bị hack.
Đảm bảo rằng một kiến trúc ứng dụng mạnh đang được áp dụng để cung cấp sự tách biệt hiệu quả và an toàn giữa các thành phần.
Nó cũng có thể giảm thiểu khả năng xảy ra cuộc tấn công này bằng cách chạy quét tự động và thực hiện kiểm tra định kỳ.
Khi các ứng dụng trực tuyến liên tục tràn ngập internet từng ngày, không phải tất cả các ứng dụng đều được bảo mật. Nhiều ứng dụng web không bảo vệ đúng cách dữ liệu nhạy cảm của người dùng như thông tin thẻ tín dụng / thông tin tài khoản ngân hàng / thông tin xác thực. Cuối cùng, tin tặc có thể đánh cắp những dữ liệu được bảo vệ yếu kém đó để thực hiện hành vi gian lận thẻ tín dụng, đánh cắp danh tính hoặc các tội phạm khác.
Hãy cho chúng tôi hiểu Tác nhân đe dọa, Vectơ tấn công, Điểm yếu về bảo mật, Tác động kỹ thuật và Tác động kinh doanh của lỗ hổng này với sự trợ giúp của sơ đồ đơn giản.
Thí dụ
Một số ví dụ điển hình về cấu hình sai bảo mật như đã cho:
Một trang web chỉ đơn giản là không sử dụng SSL cho tất cả các trang được xác thực. Điều này cho phép kẻ tấn công giám sát lưu lượng mạng và đánh cắp cookie phiên của người dùng để chiếm quyền điều khiển phiên người dùng hoặc truy cập dữ liệu cá nhân của họ.
Một ứng dụng lưu trữ số thẻ tín dụng ở định dạng được mã hóa trong cơ sở dữ liệu. Sau khi truy xuất, chúng được giải mã cho phép hacker thực hiện một cuộc tấn công SQL injection để lấy tất cả thông tin nhạy cảm dưới dạng văn bản rõ ràng. Điều này có thể tránh được bằng cách mã hóa số thẻ tín dụng bằng khóa công khai và cho phép các ứng dụng back-end giải mã chúng bằng khóa cá nhân.
BẬT tay
Step 1- Khởi chạy WebGoat và điều hướng đến Phần "Lưu trữ không an toàn". Ảnh chụp giống được hiển thị bên dưới.
Step 2- Nhập tên người dùng và mật khẩu. Đã đến lúc tìm hiểu các loại mã hóa và phương pháp mã hóa khác nhau mà chúng ta đã thảo luận trước đây.
Cơ chế phòng ngừa
Không nên lưu trữ dữ liệu nhạy cảm một cách không cần thiết và nên loại bỏ càng sớm càng tốt nếu không cần thiết nữa.
Điều quan trọng là đảm bảo rằng chúng tôi kết hợp các thuật toán mã hóa mạnh và tiêu chuẩn được sử dụng và quản lý khóa phù hợp được áp dụng.
Nó cũng có thể tránh được bằng cách tắt tính năng tự động hoàn thành trên các biểu mẫu thu thập dữ liệu nhạy cảm như mật khẩu và tắt bộ nhớ đệm cho các trang chứa dữ liệu nhạy cảm.
Hầu hết các ứng dụng web xác minh quyền truy cập cấp chức năng trước khi cung cấp chức năng đó cho người dùng. Tuy nhiên, nếu các kiểm tra kiểm soát truy cập tương tự không được thực hiện trên máy chủ, tin tặc có thể xâm nhập vào ứng dụng mà không có sự cho phép thích hợp.
Hãy cho chúng tôi hiểu Tác nhân đe dọa, Vectơ tấn công, Điểm yếu về bảo mật, Tác động kỹ thuật và Tác động kinh doanh của lỗ hổng này với sự trợ giúp của sơ đồ đơn giản.
Thí dụ
Đây là một ví dụ cổ điển về Điều khiển truy cập mức chức năng bị thiếu -
Tin tặc chỉ cần buộc các URL mục tiêu. Thông thường quyền truy cập quản trị viên yêu cầu xác thực, tuy nhiên, nếu quyền truy cập ứng dụng không được xác minh, thì người dùng chưa được xác thực có thể truy cập trang quản trị.
' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage
' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page
BẬT tay
Step 1 - Hãy để chúng tôi đăng nhập với tư cách là người quản lý tài khoản bằng cách xem qua danh sách người dùng và đặc quyền truy cập của họ.
Step 2 - Sau khi thử các kết hợp khác nhau, chúng tôi có thể phát hiện ra rằng Larry có quyền truy cập vào người quản lý tài khoản tài nguyên.
Cơ chế phòng ngừa
Theo mặc định, cơ chế xác thực sẽ từ chối tất cả quyền truy cập và cung cấp quyền truy cập vào các vai trò cụ thể cho mọi chức năng.
Trong ứng dụng dựa trên quy trình làm việc, hãy xác minh trạng thái của người dùng trước khi cho phép họ truy cập bất kỳ tài nguyên nào.
Một cuộc tấn công CSRF buộc người dùng đã xác thực (nạn nhân) gửi một yêu cầu HTTP giả mạo, bao gồm cookie phiên của nạn nhân tới một ứng dụng web dễ bị tấn công, cho phép kẻ tấn công buộc trình duyệt của nạn nhân tạo ra yêu cầu sao cho ứng dụng dễ bị tấn công coi là yêu cầu hợp pháp từ nạn nhân.
Hãy cho chúng tôi hiểu Tác nhân đe dọa, Vectơ tấn công, Điểm yếu về bảo mật, Tác động kỹ thuật và Tác động kinh doanh của lỗ hổng này với sự trợ giúp của sơ đồ đơn giản.
Thí dụ
Đây là một ví dụ cổ điển về CSRF -
Step 1 - Hãy để chúng tôi nói, ứng dụng dễ bị tấn công gửi yêu cầu thay đổi trạng thái dưới dạng văn bản thuần túy mà không có bất kỳ mã hóa nào.
http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243
Step 2 - Bây giờ tin tặc xây dựng một yêu cầu chuyển tiền từ tài khoản của nạn nhân sang tài khoản của kẻ tấn công bằng cách nhúng yêu cầu vào một hình ảnh được lưu trữ trên các trang web khác nhau dưới sự kiểm soát của kẻ tấn công -
<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#"
width = "0" height = "0" />
BẬT tay
Step 1- Hãy để chúng tôi thực hiện giả mạo CSRF bằng cách nhúng tập lệnh Java vào một hình ảnh. Ảnh chụp nhanh của vấn đề được liệt kê dưới đây.
Step 2 - Bây giờ chúng ta cần mô phỏng chuyển giao thành một hình ảnh 1x1 và làm cho nạn nhân nhấp vào giống như vậy.
Step 3 - Khi gửi tin nhắn, tin nhắn được hiển thị như được tô sáng bên dưới.
Step 4- Bây giờ nếu nạn nhân nhấp vào URL sau, quá trình chuyển được thực hiện, có thể được tìm thấy đang chặn hành động của người dùng bằng cách sử dụng bộ burp. Chúng ta có thể thấy việc chuyển giao bằng cách phát hiện nó trong Nhận tin nhắn như hình dưới đây -
Step 5 − Now upon clicking refresh, the lesson completion mark is shown.
Preventive Mechanisms
CSRF can be avoided by creating a unique token in a hidden field which would be sent in the body of the HTTP request rather than in an URL, which is more prone to exposure.
Forcing the user to re-authenticate or proving that they are users in order to protect CSRF. For example, CAPTCHA.
This kind of threat occurs when the components such as libraries and frameworks used within the app almost always execute with full privileges. If a vulnerable component is exploited, it makes the hacker’s job easier to cause a serious data loss or server takeover.
Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.
Example
The following examples are of using components with known vulnerabilities −
Attackers can invoke any web service with full permission by failing to provide an identity token.
Remote-code execution with Expression Language injection vulnerability is introduced through the Spring Framework for Java based apps.
Preventive Mechanisms
Identify all components and the versions that are being used in the webapps not just restricted to database/frameworks.
Keep all the components such as public databases, project mailing lists etc. up to date.
Add security wrappers around components that are vulnerable in nature.
Hầu hết các ứng dụng web trên internet thường chuyển hướng và chuyển tiếp người dùng đến các trang khác hoặc các trang web bên ngoài khác. Tuy nhiên, nếu không xác thực độ tin cậy của các trang đó, tin tặc có thể chuyển hướng nạn nhân đến các trang web lừa đảo hoặc phần mềm độc hại hoặc sử dụng chuyển tiếp để truy cập các trang trái phép.
Hãy cho chúng tôi hiểu Tác nhân đe dọa, Vectơ tấn công, Điểm yếu về bảo mật, Tác động kỹ thuật và Tác động kinh doanh của lỗ hổng này với sự trợ giúp của sơ đồ đơn giản.
Thí dụ
Một số ví dụ cổ điển về Chuyển hướng và Chuyển tiếp chưa được xác thực như đã cho -
Giả sử ứng dụng có một trang - redirect.jsp, có một tham số redirectrul . Tin tặc thêm một URL độc hại chuyển hướng người dùng thực hiện lừa đảo / cài đặt phần mềm độc hại.
http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com
Tất cả ứng dụng web được sử dụng để chuyển tiếp người dùng đến các phần khác nhau của trang web. Để đạt được điều tương tự, một số trang sử dụng một tham số để chỉ ra nơi người dùng sẽ được chuyển hướng nếu một thao tác thành công. Kẻ tấn công tạo một URL vượt qua kiểm tra kiểm soát quyền truy cập của ứng dụng và sau đó chuyển tiếp kẻ tấn công đến chức năng quản trị mà kẻ tấn công không có quyền truy cập.
http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp
Cơ chế phòng ngừa
Tốt hơn là nên tránh sử dụng chuyển hướng và chuyển tiếp.
Nếu nó là không thể tránh khỏi, thì nó nên được thực hiện mà không liên quan đến các tham số người dùng trong việc chuyển hướng đích.
Javascript và XML không đồng bộ (AJAX) là một trong những kỹ thuật mới nhất được sử dụng để phát triển inorder ứng dụng web nhằm mang lại trải nghiệm người dùng phong phú. Vì nó là một công nghệ mới nên có rất nhiều vấn đề bảo mật vẫn chưa được hoàn thiện và dưới đây là một số vấn đề bảo mật trong AJAX.
Bề mặt tấn công nhiều hơn vì có nhiều đầu vào hơn được bảo mật.
Nó cũng cho thấy các chức năng bên trong của các ứng dụng.
Không bảo vệ được thông tin và phiên xác thực.
Có một ranh giới rất hẹp giữa phía máy khách và phía máy chủ, do đó có khả năng mắc lỗi bảo mật.
Thí dụ
Đây là một ví dụ cho AJAX Security -
Vào năm 2006, một con sâu đã lây nhiễm dịch vụ thư yahoo bằng XSS và AJAX đã lợi dụng lỗ hổng trong xử lý sự kiện onload của Yahoo Mail. Khi một email bị nhiễm được mở, sâu thực thi JavaScript của nó, gửi một bản sao tới tất cả các địa chỉ liên hệ Yahoo của người dùng bị nhiễm.
BẬT tay
Step 1- Chúng tôi cần cố gắng thêm nhiều phần thưởng hơn vào bộ phần thưởng được phép của bạn bằng cách sử dụng phương pháp tiêm XML. Dưới đây là ảnh chụp nhanh của kịch bản.
Step 2- Đảm bảo rằng chúng tôi chặn cả yêu cầu và phản hồi bằng Burp Suite. Cài đặt tương tự như hình dưới đây.
Step 3- Nhập số tài khoản như đã cho trong kịch bản. Chúng tôi sẽ có thể nhận được danh sách tất cả các phần thưởng mà chúng tôi đủ điều kiện nhận. Chúng tôi đủ điều kiện nhận 3 phần thưởng trong số 5 phần thưởng.
Step 4- Bây giờ chúng ta hãy nhấp vào 'Gửi' và xem những gì chúng ta nhận được trong XML phản hồi. Như được hiển thị bên dưới, ba phần thưởng mà chúng tôi đủ điều kiện được chuyển cho chúng tôi dưới dạng XML.
Step 5 - Bây giờ chúng ta hãy chỉnh sửa các XML đó và thêm cả hai phần thưởng khác.
Step 6- Bây giờ tất cả các phần thưởng sẽ được hiển thị cho người dùng để họ lựa chọn. Chọn những cái mà chúng tôi đã thêm và nhấp vào 'Gửi'.
Step 7 - Thông báo sau xuất hiện với nội dung "* Xin chúc mừng. Bạn đã hoàn thành bài học này thành công."
Cơ chế phòng ngừa
Phía khách hàng -
- Sử dụng .innerText thay vì .innerHtml.
- Không sử dụng eval.
- Đừng dựa vào logic của máy khách để bảo mật.
- Tránh viết mã tuần tự hóa.
- Tránh xây dựng XML động.
- Không bao giờ truyền bí mật cho khách hàng.
- Không thực hiện mã hóa trong mã phía máy khách.
- Không thực hiện logic tác động đến bảo mật ở phía máy khách.
Phía máy chủ -
- Sử dụng bảo vệ CSRF.
- Tránh viết mã tuần tự hóa.
- Người dùng có thể gọi dịch vụ trực tiếp.
- Tránh xây dựng XML bằng tay, hãy sử dụng khuôn khổ.
- Tránh xây dựng JSON bằng tay, hãy sử dụng một khuôn khổ hiện có.
Trong các ứng dụng dựa trên web hiện đại, việc sử dụng các dịch vụ web là không thể tránh khỏi và chúng cũng dễ bị tấn công. Vì các dịch vụ web yêu cầu tìm nạp từ nhiều trang web, các nhà phát triển phải thực hiện một số biện pháp bổ sung để tránh bất kỳ hình thức xâm nhập nào của tin tặc.
BẬT tay
Step 1- Điều hướng đến khu vực dịch vụ web của Webgoat và đi tới Quét WSDL. Bây giờ chúng tôi cần lấy chi tiết thẻ tín dụng của một số số tài khoản khác. Ảnh chụp nhanh của kịch bản như được đề cập bên dưới.
Step 2 - Nếu chúng ta chọn tên, lệnh gọi hàm 'getFirstName' được thực hiện thông qua yêu cầu SOAP xml.
Step 3- Bằng cách mở WSDL, chúng ta có thể thấy rằng có một phương pháp để truy xuất thông tin thẻ tín dụng cũng như 'getCreditCard'. Bây giờ, hãy để chúng tôi xáo trộn các đầu vào bằng bộ Burp như hình dưới đây -
Step 4 - Bây giờ chúng ta hãy sửa đổi các đầu vào bằng bộ Burp như hình dưới đây -
Step 5 - Chúng tôi có thể lấy thông tin thẻ tín dụng của những người dùng khác.
Cơ chế phòng ngừa
Vì các thông báo SOAP dựa trên XML, nên tất cả các thông tin xác thực đã chuyển phải được chuyển đổi sang định dạng văn bản. Do đó, người ta phải rất cẩn thận trong việc chuyển thông tin nhạy cảm mà thông tin này phải luôn được mã hóa.
Bảo vệ tính toàn vẹn của thông báo bằng cách thực hiện các cơ chế như tổng kiểm tra được áp dụng để đảm bảo tính toàn vẹn của gói tin.
Bảo vệ tính bí mật của thư - Mã hóa không đối xứng được áp dụng để bảo vệ các khóa phiên đối xứng, trong nhiều cách triển khai chỉ hợp lệ cho một giao tiếp và sau đó sẽ bị loại bỏ.
Tràn bộ đệm phát sinh khi một chương trình cố gắng lưu trữ nhiều dữ liệu hơn trong vùng lưu trữ dữ liệu tạm thời (bộ đệm) so với dự định lưu trữ. Vì bộ đệm được tạo ra để chứa một lượng dữ liệu hữu hạn, thông tin bổ sung có thể tràn vào bộ đệm liền kề, do đó làm hỏng dữ liệu hợp lệ được giữ trong chúng.
Thí dụ
Đây là một ví dụ cổ điển về tràn bộ đệm. Nó cho thấy một sự cố tràn bộ đệm đơn giản gây ra bởi tình huống đầu tiên dựa vào dữ liệu bên ngoài để kiểm soát hành vi của nó. Không có cách nào để giới hạn số lượng dữ liệu mà người dùng đã nhập và hành vi của chương trình phụ thuộc vào số lượng ký tự mà người dùng đã nhập vào bên trong.
...
char bufr[BUFSIZE];
gets(bufr);
...
BẬT tay
Step 1- Chúng tôi cần đăng nhập với tên và số phòng để truy cập internet. Đây là ảnh chụp nhanh kịch bản.
Step 2 - Chúng tôi cũng sẽ kích hoạt "Hiện các trường biểu mẫu ẩn" trong Burp Suite như hình dưới đây -
Step 3- Bây giờ chúng tôi gửi một đầu vào trong trường tên và số phòng. Chúng tôi cũng thử và đưa một số khá lớn vào trường số phòng.
Step 4- Các trường ẩn được hiển thị như hình dưới đây. Chúng tôi nhấp vào chấp nhận các điều khoản.
Step 5 - Cuộc tấn công thành công như do tràn bộ đệm, nó bắt đầu đọc các vị trí bộ nhớ liền kề và hiển thị cho người dùng như hình dưới đây.
Step 6- Bây giờ chúng ta hãy đăng nhập bằng dữ liệu được hiển thị. Sau khi ghi nhật ký, thông báo sau được hiển thị:
Cơ chế phòng ngừa
- Đánh giá mã
- Đào tạo nhà phát triển
- Công cụ biên dịch
- Phát triển các chức năng An toàn
- Quét định kỳ
Tấn công từ chối dịch vụ (DoS) là nỗ lực của tin tặc nhằm làm cho tài nguyên mạng không khả dụng. Nó thường làm gián đoạn máy chủ, tạm thời hoặc vô thời hạn, máy chủ được kết nối với internet. Các cuộc tấn công này thường nhắm vào các dịch vụ được lưu trữ trên các máy chủ web quan trọng như ngân hàng, cổng thanh toán thẻ tín dụng.
Các triệu chứng của DoS
- Hiệu suất mạng chậm bất thường.
- Không có sẵn một trang web cụ thể.
- Không có khả năng truy cập bất kỳ trang web nào.
- Số lượng email spam nhận được tăng đáng kể.
- Từ chối lâu dài quyền truy cập vào web hoặc bất kỳ dịch vụ internet nào.
- Không có sẵn một trang web cụ thể.
BẬT tay
Step 1- Khởi chạy WebGoat và điều hướng đến phần 'Từ chối dịch vụ'. Ảnh chụp nhanh của kịch bản được đưa ra dưới đây. Chúng tôi cần đăng nhập nhiều lần ở đó bằng cách vi phạm kích thước nhóm luồng DB tối đa.
Step 2- Đầu tiên chúng ta cần lấy danh sách các lần đăng nhập hợp lệ. Chúng tôi sử dụng SQL Injection trong trường hợp này.
Step 3 - Nếu nỗ lực thành công, thì nó sẽ hiển thị tất cả các thông tin xác thực hợp lệ cho người dùng.
Step 4- Bây giờ đăng nhập với mỗi người dùng này trong ít nhất 3 phiên khác nhau để thực hiện cuộc tấn công DoS thành công. Như chúng ta biết rằng kết nối DB chỉ có thể xử lý hai luồng, bằng cách sử dụng tất cả thông tin đăng nhập, nó sẽ tạo ra ba luồng giúp cuộc tấn công thành công.
Cơ chế phòng ngừa
Thực hiện xác nhận đầu vào kỹ lưỡng.
Tránh các hoạt động tiêu tốn nhiều CPU.
Tốt hơn là tách đĩa dữ liệu khỏi đĩa hệ thống.
Các nhà phát triển thường trực tiếp sử dụng hoặc nối đầu vào có khả năng dễ bị tấn công với tệp hoặc cho rằng tệp đầu vào là chính hãng. Khi dữ liệu không được kiểm tra đúng cách, điều này có thể dẫn đến việc máy chủ web xử lý hoặc gọi nội dung dễ bị tấn công.
Thí dụ
Một số ví dụ cổ điển bao gồm:
- Tải tệp .jsp lên cây web.
- Tải lên .gif để được thay đổi kích thước.
- Tải lên các tệp lớn.
- Tải lên tệp có chứa thẻ.
- Tải tệp .exe lên cây web.
BẬT tay
Step 1- Khởi chạy WebGoat và điều hướng đến phần Thực thi tệp độc hại. Ảnh chụp nhanh của kịch bản được đưa ra dưới đây:
Step 2 - Để hoàn thành bài học này, chúng ta cần tải lên guest.txt ở vị trí đã nói ở trên.
Step 3- Hãy để chúng tôi tạo một tệp jsp sao cho tệp guest.txt được tạo khi thực thi jsp. Việc đặt tên cho jsp không có vai trò gì trong ngữ cảnh này vì chúng tôi đang thực thi nội dung của tệp jsp.
<HTML>
<% java.io.File file = new
java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt");
file.createNewFile(); %>
</HTML>
Step 4- Bây giờ tải lên tệp jsp và sao chép vị trí liên kết của cùng sau khi tải lên. Quá trình tải lên đang mong đợi một hình ảnh, nhưng chúng tôi đang tải lên một jsp.
Step 5 - Bằng cách điều hướng đến tệp jsp, sẽ không có bất kỳ thông báo nào cho người dùng.
Step 6 - Bây giờ làm mới phiên mà bạn đã tải lên tệp jsp và bạn sẽ nhận được thông báo “* Xin chúc mừng. Bạn đã hoàn thành bài học thành công”.
Cơ chế phòng ngừa
- Bảo mật các trang web bằng cách sử dụng quyền của trang web.
- Áp dụng các biện pháp đối phó để bảo mật ứng dụng web.
- Hiểu tài khoản người dùng và nhóm tích hợp trong IIS 7.0.
Có nhiều công cụ khác nhau có sẵn để thực hiện kiểm tra bảo mật của một ứng dụng. Có một số công cụ có thể thực hiện kiểm tra bảo mật đầu cuối trong khi một số công cụ dành riêng để phát hiện một loại lỗ hổng cụ thể trong hệ thống.
Công cụ nguồn mở
Một số công cụ kiểm tra bảo mật nguồn mở như đã cho -
Không. | Tên công cụ |
---|---|
1 | Zed Attack Proxy Cung cấp Máy quét tự động và các công cụ khác để phát hiện các lỗi bảo mật. https://www.owasp.org |
2 | OWASP WebScarab Được phát triển bằng Java để phân tích các yêu cầu Http và Https. https://www.owasp.org/index.php |
3 | OWASP Mantra Hỗ trợ khung kiểm tra bảo mật đa ngôn ngữ https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework |
4 | Burp Proxy Công cụ chặn & điều chỉnh lưu lượng truy cập và hoạt động với chứng chỉ SSL tùy chỉnh. https://www.portswigger.net/Burp/ |
5 | Firefox Tamper Data Sử dụng giả mạo dữ liệu để xem và sửa đổi tiêu đề HTTP / HTTPS và các thông số đăng https://addons.mozilla.org/en-US |
6 | Firefox Web Developer Tools Tiện ích mở rộng Nhà phát triển web thêm nhiều công cụ dành cho nhà phát triển web khác nhau vào trình duyệt. https://addons.mozilla.org/en-US/firefox |
7 | Cookie Editor Cho phép người dùng thêm, xóa, chỉnh sửa, tìm kiếm, bảo vệ và chặn cookie https://chrome.google.com/webstore |
Bộ công cụ cụ thể
Các công cụ sau có thể giúp chúng tôi phát hiện một loại lỗ hổng cụ thể trong hệ thống:
Không. | Liên kết |
---|---|
1 | DOMinator Pro − Testing for DOM XSS https://dominator.mindedsecurity.com/ |
2 | OWASP SQLiX − SQL Injection https://www.owasp.org/index.php |
3 | Sqlninja − SQL Injection http://sqlninja.sourceforge.net/ |
4 | SQLInjector − SQL Injection https://sourceforge.net/projects/safe3si/ |
5 | sqlpowerinjector − SQL Injection http://www.sqlpowerinjector.com/ |
6 | SSL Digger − Testing SSL https://www.mcafee.com/us/downloads/free-tools |
7 | THC-Hydra − Brute Force Password https://www.thc.org/thc-hydra/ |
số 8 | Brutus − Brute Force Password http://www.hoobie.net/brutus/ |
9 | Ncat − Brute Force Password https://nmap.org/ncat/ |
10 | OllyDbg − Testing Buffer Overflow http://www.ollydbg.de/ |
11 | Spike − Testing Buffer Overflow https://www.immunitysec.com/downloads/SPIKE2.9.tgz |
12 | Metasploit − Testing Buffer Overflow https://www.metasploit.com/ |
Công cụ kiểm tra hộp đen thương mại
Dưới đây là một số công cụ kiểm tra hộp đen thương mại giúp chúng tôi phát hiện các vấn đề bảo mật trong các ứng dụng mà chúng tôi phát triển.
S.Không | Dụng cụ |
---|---|
1 | NGSSQuirreL https://www.nccgroup.com/en/our-services |
2 | IBM AppScan https://www-01.ibm.com/software/awdtools/appscan/ |
3 | Acunetix Web Vulnerability Scanner https://www.acunetix.com/ |
4 | NTOSpider https://www.ntobjectives.com/products/ntospider.php |
5 | SOAP UI https://www.soapui.org/Security/getting-started.html |
6 | Netsparker https://www.mavitunasecurity.com/netsparker/ |
7 | HP WebInspect http://www.hpenterprisesecurity.com/products |
Trình phân tích mã nguồn miễn phí
S.Không | Dụng cụ |
---|---|
1 | OWASP Orizon https://www.owasp.org/index.php |
2 | OWASP O2 https://www.owasp.org/index.php/OWASP_O2_Platform |
3 | SearchDiggity https://www.bishopfox.com/resources/tools |
4 | FXCOP https://www.owasp.org/index.php/FxCop |
5 | Splint http://splint.org/ |
6 | Boon https://www.cs.berkeley.edu/~daw/boon/ |
7 | W3af http://w3af.org/ |
số 8 | FlawFinder https://www.dwheeler.com/flawfinder/ |
9 | FindBugs http://findbugs.sourceforge.net/ |
Máy phân tích mã nguồn thương mại
Các bộ phân tích này kiểm tra, phát hiện và báo cáo các điểm yếu trong mã nguồn, dễ có lỗ hổng bảo mật -
S.Không | Dụng cụ |
---|---|
1 | Parasoft C/C++ test https://www.parasoft.com/cpptest/ |
2 | HP Fortify http://www.hpenterprisesecurity.com/products |
3 | Appscan http://www-01.ibm.com/software/rational/products |
4 | Veracode https://www.veracode.com |
5 | Armorize CodeSecure http://www.armorize.com/codesecure/ |
6 | GrammaTech https://www.grammatech.com/ |