Thứ Sáu, 9 tháng 6, 2017

About me

  Đôi điều về bản thân
Xin chào các bạn độc giả. Tôi là Khanh, hiện đang là sinh viên năm 4.

  Về blog
Đây là một blog riêng của tôi viết về đủ thứ trên đời này liên quan đến công nghệ, về những thứ hay ho, những kinh nghiệm đời thực tôi học được trong trường, ngoài đời.
Với niềm yêu thích việc lập trình, thông qua blog này tôi sẽ chỉ cho các bạn thấy lập trình không hề khô khan như chúng ta vẫn nghĩ.
Tôi viết blog này với mục đích nâng cao khả năng diễn đạt, trình bày vấn đề, cũng như chia sẻ kinh nghiệm và kiến thức cho mọi người. Mọi comment góp ý hay ném đá, miễn là ko mang tính xúc phạm, đều được hoan nghênh.

Chúc các bạn có những phút giây vui vẻ và tìm được những kiến thức bổ ích khi đọc blog của mình!

Thứ Hai, 5 tháng 6, 2017

[The Fact]Xóa bỏ những ảo tưởng về Lập Trình Viên

Bất kỳ công việc nào khi bạn khởi đầu cũng sẽ gặp nhiều khó khăn, thử thách. Dù yêu thích công nghệ, dù đam mê khám phá, nhiều bạn trẻ vẫn ngần ngại bước vào thế giới lập trình. Liệu để trở thành lập trình viên có khó như mọi người nghĩ không?






Framgia

Thứ Tư, 10 tháng 5, 2017

[Chia sẻ]10 website dạy lập trình miễn phí



Nếu chưa có điều kiện theo học các khóa đào tạo chính quy, bạn hoàn toàn có thể học kiến thức lập trình cơ bản trên mạng nhờ những website dạy miễn phí như GitHub, edX hay Free Code Camp.


Dưới đây là 10 website để bạn bắt đầu làm quen với lập trình:
1. Codecademy
Đúng như tên gọi, Codecademy dạy bạn mọi thứ cơ bản để lập trình. Nó làm điều này thông qua các khóa học cụ thể, cung cấp đủ nguyên liệu để học theo chủ đề lựa chọn. Codecademy có nhiều đề tài từ học một ngôn ngữ cụ thể (HTML, Java, Python) đến học cách viết một website. Nếu thực sự yêu thích Codecademy, bạn có thể mua gói trả tiền để mở khóa các chương trình hấp dẫn.
2. edX
Dù edX là một website cung cấp tất cả khóa học theo yêu cầu, nó có khá nhiều các khóa học lập trình máy tính trong thư viện. edX do hai đại học hàng đầu thế giới là MIT và Harvard thành lập năm 2012, vì thế bạn chắc chắn được tiếp cận các khóa học chất lượng ở đây. Bạn có thể tự học hoặc chọn giảng viên.
3. MIT Open Courseware
Nói về MIT, không thể không nhắc đến chương trình học trực tuyến của họ. Bạn có thể tìm kiếm trong thư viện hoặc duyệt trong mục khoa học máy tính để tìm các khóa học liên quan. Có khá nhiều chương trình, chẳng hạn Nhập môn khoa học máy tính, C primer, và chúng đều miễn phí. Có một chút khác biệt so với các website lập trình miễn phí khác là bạn tải về các nguyên liệu thô thay vì video hay bài học.
4. Khan Academy
Nếu muốn một bộ sưu tập video để theo dõi ở nhà, Khan Academy là những gì bạn cần. Chỉ cần duyệt qua mục lập trình của họ và chọn ra những gì bạn thích nhất. Các chủ đề cơ bản trải rộng từ lập trình là gì cho đến các tính năng lập trình cơ bản.
5. Udemy
Dù Udemy tính phí các khóa học, nó vẫn cung cấp một số khóa miễn phí để học thử. Bạn có thể chọn “Free” trong bộ lọc giá khi tìm kiếm. Mỗi khóa học lại có xếp hạng và số người tham dự, đồng nghĩa bạn có thể khoanh vùng khóa nào đáng học.
6. Free Code Camp
Free Code Camp là website khá thú vị: Bạn học lập trình trực tuyến cùng họ, sau khoảng 1 năm, bạn có thể tham gia phát triển các dự án nguồn mở cho tổ chức phi lợi nhuận. Ý tưởng là bạn sử dụng thời gian và kinh nghiệm tại Free Code Camp để chuyển hóa thành danh mục ngoài đời thực, giúp tìm được việc làm. Free Code Camp yêu cầu tạo tài khoản GitHub trong quá trình đăng ký.
7. GitHub
GitHub chứa đầy các mẹo lập trình. Nó được Victor Felder duy trì, người tạo ra cơ sở dữ liệu nguyên liệu lập trình miễn phí và hợp pháp. Kết quả là bạn có một kho tài liệu để học và tận dụng.
8. The Code Player
Trong số tất cả các website dạy lập trình miễn phí, The Code Player là lựa chọn tốt cho những ai muốn học theo ví dụ. Chọn một khóa học, nó sẽ cung cấp cho các bạn từng bước xây dựng cái gì đó từ đầu. Sau đó, bạn có thể tự lập trình hoặc sao chép đoạn mã cho dự án riêng.
9. The Odin Project
The Odin Project giúp bạn biết được cách phát triển một website như thế nào. Các khóa học của nó cho phép bạn làm quen với các ngôn ngữ như Ruby on Rails, HTML5, Javascript… Điều khiến Odin Project đặc biệt thú vị là sau khi học xong, bạn được cung cấp một số mẹo khi đăng ký làm lập trình web.
10. Code Wars
Code Wars là lựa chọn tuyệt vời khi bạn đã học xong các khóa cơ bản về lập trình và muốn có một nơi để vừa học, vừa thử thách kỹ năng. Bạn có thể tham gia vào các bài thi của cộng đồng (kata) liên quan đến ngôn ngữ mà bạn học. Viết giải pháp và gửi lên, sau khi cuộc thi kết thúc, mọi giải pháp đều được công bố. Bạn có thể xem mọi người xử lý vấn đề như thế nào và rút ra bài học cho mình.
khanh phạm

Thứ Năm, 6 tháng 4, 2017

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

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:

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:
  • 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
  • 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:
    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

    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:
        • Nội dung trang web của hacker
        • 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

    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:
      • 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: