@manhnguyenv

Welcome to my blog!

Bảo mật

August 17, 2017 01:01

OAuth là gì?

OAuth là một chuẩn xác thực mở được rất nhiều các website và phần mềm sử dụng.

OpenID là gì?

OpenID là một tiêu chuẩn mở và là một giao thức authen được phân cấp. Được phát triển bởi tổ chức phi lợi nhuận OpenID Foundation, OpenID cho phép user có thể được authen bởi rất nhiều website (Relying Parties hoặc RP) sử dụng service của bên thứ 3

Khác nhau giữa OAuth & OpenID

http://www.codehub.vn/OpenID-va-OAuth-Khac-Nhau-Nhu-The-Nao

OAuth không phải là OpenID

OpenID cũng là một dạng xác thực danh tính dùng nick từ tài khoản xxx để đăng nhập vào trang yyy. Về nguyên tắc thì hai loại này giống nhau nhưng cách hoạt động của chúng thì lại khác nhau. OpenID đòi hỏi người dùng phải cung cấp thông tin cá nhân còn OAuth thì không.

OpenID is a protocol for authentication while OAuth is for authorization

OAuth 2.0 là gì?

OAuth 2.0 Authorization Framework [RFC6749]

OAuth 2.0 Bearer Token Usage [RFC6750]

https://blogs.msdn.microsoft.com/webdev/2016/10/27/bearer-token-authentication-in-asp-net-core/

http://kevinchalet.com/2017/01/30/implementing-simple-token-authentication-in-aspnet-core-with-openiddict/

http://kevinchalet.com/2016/07/13/creating-your-own-openid-connect-server-with-asos-introduction/

http://kevinchalet.com/2016/07/13/creating-your-own-openid-connect-server-with-asos-creating-your-own-authorization-provider/

http://kevinchalet.com/2016/07/13/creating-your-own-openid-connect-server-with-asos-implementing-the-resource-owner-password-credentials-grant/

https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server

https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Samples/tree/master/samples/

https://github.com/aspnet/Security

Choose type of Authentication & Authorization

https://medium.com/@robert.broeckelmann/when-to-use-which-oauth2-grants-and-oidc-flows-ec6a5c00d864

https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/

Bearer in ASP.NET Core

https://dev.to/samueleresca/developing-token-authentication-using-aspnet-core

https://github.com/samueleresca/Blog.TokenAuthGettingStarted

https://pioneercode.com/post/authentication-in-a-asp-dot-net-core-api-part-1-identity-access-denied

https://pioneercode.com/post/authentication-in-a-asp-dot-net-core-api-part-2-identity-access-granted

https://pioneercode.com/post/authentication-in-an-asp-dot-net-core-api-part-3-json-web-token

Area in ASP.NET Core

https://pioneercode.com/post/creating-areas-in-asp-net-core

Pagination in ASP.NET Core

https://pioneercode.com/post/asp-net-core-mvc-pagination-using-a-tag-helper

https://stackoverflow.com/questions/37708266/bearer-token-authentication-in-asp-net-core

Put app.UseMvc() at the end of your pipeline and it should work:

app.UseJwtBearerAuthentication(new JwtBearerOptions
{
    AutomaticAuthenticate = true,
    AutomaticChallenge = true,
    TokenValidationParameters = tokenValidationParameters,
    AuthenticationScheme = JwtBearerDefaults.AuthenticationScheme,
});

app.UseMvc();

OpenID Connect là gì?

http://openid.net/connect/

Bảo mật nhập môn

Sử dụng Cookie đúng cách để tránh những lỗi bảo mật không đáng có ntn?

Nếu website của bạn sử dụng RESTful API, đừng sử dụng cookie để authorize người dùng mà hãy dùng OAuth hoặc WebToken. Token này được vào Header của mỗi request nên sẽ không bị dính lỗi CRSF nhé.

Bảo mật Cookie

https://toidicodedao.com/2016/10/25/bao-mat-cookie/

Bảo mật cơ bản phần 1

https://toidicodedao.com/2016/09/13/bao-mat-co-ban-phan-1/

Ẩn giấu thông tin hệ thống

https://toidicodedao.com/2016/11/01/an-thong-tin-he-thong/

Quản lý người dùng

https://toidicodedao.com/tag/juno_okyo/

Quản lý người dùng đúng cách

https://toidicodedao.com/2016/12/20/quan-ly-user-dung-cach/

Open Web Application Security Project (OWASP) là gì?

1) SQL Injection

https://toidicodedao.com/2016/11/15/lo-hong-sql-injection-than-thanh/

2) XSS

https://toidicodedao.com/2016/10/18/lo-hong-bao-mat-xss/

3) CSRF

https://toidicodedao.com/2016/11/29/csrf-cu-lua-ngoan-muc/

4) Insecure Direct Object References

https://toidicodedao.com/2016/11/22/lo-hong-bao-mat-insecure-direct-object-references/

Security in ASP.NET Core

August 4, 2017 23:47

ASP.NET Core Custom User Manager

http://sikorsky.pro/en/blog/aspnet-core-custom-user-manager

Keep your ASP.NET Core secrets safe in production using Azure Application Settings

https://jonhilton.net/2017/06/28/keep-your-asp-net-core-secrets-safe-in-production-using-azure-application-settings/

Redis InMemory Cache in ASP.NET Core MVC - Gary Woodfine

https://garywoodfine.com/redis-inmemory-cache-asp-net-mvc-core/

https://github.com/garywoodfine/redis-mvc-core

https://garywoodfine.com/why-when-and-how-to-use-redis-in-asp-net-mvc-core/

Building a scheduled task in ASP.NET Core/Standard 2.0

https://blog.maartenballiauw.be/post/2017/08/01/building-a-scheduled-cache-updater-in-aspnet-core-2.html

C# 7.0

https://blog.xamarin.com/getting-started-c-7

Entity Framework Core - Gary Woodfine

https://garywoodfine.com/how-to-seed-your-ef-core-database/

https://garywoodfine.com/using-ef-core-in-a-separate-class-library-project/

Cutting Edge - Finding the Cheese in ASP.NET Core

https://msdn.microsoft.com/en-us/magazine/mt784659.aspx

API Testing with Postman

http://blog.getpostman.com/2017/07/28/api-testing-tips-from-a-postman-professional/

http://blog.getpostman.com/2015/09/03/how-to-write-powerful-automated-api-tests-with-postman-newman-and-jenkins/

XML & JSON in ASP.NET Core

https://andrewlock.net/formatting-response-data-as-xml-or-json-based-on-the-url-in-asp-net-core/

Serialize all errors as JSON in ASP.NET Core

https://www.recaffeinate.co/post/serialize-errors-as-json-in-aspnetcore/

Adding Azure AD authentication to an ASP.NET Core web site is almost too easy!

https://sparre.io/2/adding-azure-ad-authentication-to-an-aspnet-core-web-site-is

Angular 2 - Gary Woodfine

https://garywoodfine.com/building-angular2-basic-application/

https://garywoodfine.com/angular-2-reactive-forms/

Security Asp.Net Core

July 16, 2017 00:55

https://andrewlock.net/introduction-to-authentication-with-asp-net-core/

https://stormpath.com/blog/tutorial-policy-based-authorization-asp-net-core

https://social.technet.microsoft.com/wiki/contents/articles/36804.asp-net-core-mvc-authentication-and-role-based-authorization-with-asp-net-core-identity.aspx

https://jonhilton.net/2017/05/03/login-authentication-asp-net-core-web-api-big-picture/

Hacker

May 19, 2017 10:41

Một số kỹ thuật tấn công web

Một số kỹ thuật tấn công web mà hacker hay sử dụng để lấy cắp thông tin, phá hỏng dữ liệu trên hệ thống đó là:

  • XSS (Cross-Site Scripting):
    Là một trong những kĩ thuật tấn công phổ biến nhất hiện nay, đồng thời nó cũng là một trong những vấn đề bảo mật quan trọng đối với các nhà phát triển web và cả những người sử dụng web. XSS là một kỹ thuật tấn công bằng cách chèn vào các website động những thẻ HTML hay những đoạn scrip nguy hiểm có thể gây hại cho những người sử dụng khác. Trong đó, những đoạn mã nguy hiểm được chèn vào hầu hết được viết bằng các Client-Site Scrip như JavaScrip, Jscrip.. và cũng có thể là các thẻ HTML.

  • CSRF (Cross-site Request Forgery):
    Là kỹ thuật tấn công bằng cách sử dụng quyền chứng thực của người dùng đối với một website. Nó là kỹ thuật tấn công vào người dùng, dựa vào đó hacker có thể thực thi những thao tác phải yêu cầu sự chứng thực.

  • SQL injection:
    SQL Injection là một kỹ thuật lợi dụng những lỗ hổng về câu truy vấn lấy dữ liệu của những website không an toán, đây là một kỹ thuật tấn công rất phổ biến và sự thành công của nó cũng tương đối cao.

I. Cách thực hiện

1. XSS

Cho phép kẻ tấn công nhúng mã đọc Javacsript, VBScript, ActiveX, HTML, hoặc Flash vào một trang năng động, dễ bị đánh lừa người sử dụng, thực hiện kịch bản trên máy tính của mình để thu thập dữ liệu. Kỹ thuật này không tấn công vào CSDL hệ thống như SQL injection mà chúng tấn công trực tiếp từ phía người dùng bằng cách xâm nhập hệ thống bằng các đoạn mã đơn giản để lấy cắp cookies và session từ đó chúng có thể thao túng người dùng cướp quyền truy cập tài khoản mà không cần tới mật khẩu.

  • Non-persistent(Reflected) là loại phổ biến nhất: Loại này xuất hiện khi dữ liệu được cung cấp từ một web client nào đó. Hacker khi muốn tấn công thì điều đầu tiên là sẽ phải tìm ra lỗ hổng bảo mật trên website bằng cách gắn một đoạn mã test vào web client để web client gửi đến server và chờ phản hồi của web server để tìm ra lỗ hổng bảo mật.Hacker tấn công dựa vào sự thiếu chú ý về việc lọc dữ liệu vào từ URL vủa website và gắn thêm những đoạn mã độc vào đây để thực hiện hành vi tấn công website. Loại này thì chỉ có tác dụng trong một lần.

    Ví dụ : Có thể một request được gửi từ các form dữ liệu hoặc cũng có thể chỉ là các URL: http://www.example.com/search?query=alert('XSS was found !');

  • Stored XSS: Là một biến thể tàn phá gây hậu quả rất nặng nề. Loại này xảy ra khi dữ liệu do các hacker cung cấp được lưu trữ trên các máy chủ thông qua một số chức năng trên website và từ đó về sau thì các dữ liệu này hiển nhiên được hiển thị một cách bình thường trên các trình duyệt của người dùng mà không cần tới HTML riêng nữa. Và khi người dùng click vào những phần bị gắn mã độc thì đã bị dính XSS. Đoạn mã chèn thêm vào được lưu trữ vào CSDL trên server dưới dạng các comment trong blog, mesage, forum hay visitor log

    Ví dụ: Khi đăng ký thành viên, phần giới thiêu về bản thân, nếu hacker nhập vào mã XSS và website không kiểm tra kỹ dữ liệu đầu vào, thì mỗi khi truy cập trang thành viên của hacker đó, bạn sẽ bị khai thác.

    Mô hình XSS

    123.png

Từ những điều này có thể thấy Stored XSS nguy hiểm hơn Reflected XSS rất nhiều, đối tượng bị ảnh hưởng có thế là tất cả nhưng người sử dụng ứng dụng web đó. Và nếu nạn nhân có vai trò quản trị thì còn có nguy cơ bị chiếm quyền điều khiển web.

2. CSRF

Tấn công sử dụng kỹ thuật này dành cho người am hiểu về hệ thống, có thể đã từng phát triển hệ thống đó, hoặc một mã nguồn mở, hoặc một mã nguồn nào đó đã được công khai code. Hacker thực hiện gửi tin nhắn dến Admin, khi admin đọc tin nhắn này trình duyệt sẽ request đến link đó và lấy cookie của trình duyệt và tiến hành active. Trường hợp không gửi được mail, giả sử ta biết rằng admin đang login hacker có thể send 1 trang web mà hacher lập ra, trong đó có đoạn code độc hại rồi send qua yahoo hay gì gì đó, khi đó admin viếng thăm vào và thực hiện các thao tác trên. Như vậy hacker thực hiện một truy vấn trái phép dựa vào chính người dùng

3. SQl Injection

Chắc hẳn các bạn đã biết mô hình hoạt động của website rồi nhỉ? Khi một request được gửi từ client thì ngôn ngữ SERVER như PHP sẽ lấy các thông tin từ request đó. Nhưng bản thân nó không hề phát hiện ra những thông tin đó có chứa những câu SQL độc, vì thế công việc này ta phải đổ trách nhiệm tới kinh nghiệm của lập trình viên.
- Giả sử tôi có một trang đăng nhập với hai thông tin là tên đăng nhập và mật khẩu. Và đoạn code xử lý tấn công sql injection của tôi có dạng như sau:
Selection_108.png

 Nếu nhập ” ‘ OR 1=1″ vào ô text user và pass thì câu lệnh SQL sẽ có dạng:
`SELECT * FROM T_USERS WHERE username=” OR 1=1 and password=” OR 1=1;`

Chạy câu truy vấn này lên thì kết quả nó trả về là danh sách user nên nếu code cùi cùi thì login được luôn.

Trên đây là một ví dụ điển hình thôi, chứ thực tế thì hacker còn rất nhiều mưu mẹo khác. Tuy nhiên chung quy lại với kỹ thuật tấn công SQL Injection ta vẫn có thể không chế được nó.

II. Cách phòng chống:

1. XSS

Cách phòng chống tốt nhất XSS là theo nguyên tắc filter input và escape output. Để làm việc này thì hiện tại có khá nhiều bộ lọc để chúng ta lựa chọn. Dựa vào cách khắc phục đó bạn có thể dùng một thư viện viết bằng PHP cho phép filter HTML để ngăn chặn kẻ xấu post mã độc XSS thông qua website của bạn. Thư viện có sẵn đó là HTML Purifier. Đây là bộ thư viện rất mạnh dùng triển kahi trong code của mình để chống XSS. Được xây dựng theo mô hình ÔP nên sử dụng rất dễ, sau thao tác include file thư viện, chỉ cần tạo instance của đối tượng HTML Purifier và gọi phương thức purify() là có thể filter được dữ liệu đầu vào

2. CSRF

Thông thường để tránh tấn công ta sẽ chia làm hai đối tượng, một là đối tượng coder và hai là đối tượng người dùng cuối (user).
- Với đối tượng người dùng cuối thì:
- Hạn chế sử dụng login vào hệ thống khi nói chuyện tiếp xúc với những người lạ qua các kênh khác nhau, những email không rõ nguồn gốc. Khi không dùng hệ thống thì lập tức logout.
- Nên login vào một máy riêng và không cho người thứ 2 tiếp xúc với máy đó.
- Thay đổi mật khẩu liên tục, và chọn những mật khẩu khó đoán, có kỹ tự đặc biệt. Vì hiện nay có rất nhiều phần mềm dò pass.
- Với đối tượng coder:
- Thực hiện tạo những token auto và random với từng máy, từng trình duyệt và thiết lập thời gian sống cho token đó.
- Không sử dụng phương thức GET với những request mà có ảnh hưởng đến CSDL.
- Khi lấy dữ liệu từ người dùng thì kiểm tra chặt chẽ.
- URL trong admin càng khó nhớ càng bí hiểm càng tốt.

3. SQL Injection

  • Nhận dữ liệu kiểu INT
  • Viết lại đường dẫn có thể chống SQL Injection
  • Sử dụng hàm sprintf và mysql_real_escape_string để các định kiểu dữ liệu cho câu truy vấn.

Trên đây là 3 cách mà hacker thường dùng để có thể xâm nhập vào hệ thống. Vì vậy Coder thì nên biết để phòng tránh và Tester nên biết để tìm ra các lỗi này để hacker khó có thể xâm nhập được vào hệ thống.

Web Security

May 19, 2017 10:36

Agenda:

Có thể bạn nghĩ rằng, trang web của bạn không có bất kỳ thông tin có giá trị nào để mà bị tin tặc (hacker) tấn công, nhưng bạn đã nhầm, các trang web bị xâm nhập mọi lúc. Phần lớn các xâm nhập an ninh web này không phải là để ăn cắp dữ liệu hoặc phá hỏng website của bạn. Thay vào đó, tin tặc cố gắng sử dụng máy chủ của bạn như là một địa chỉ email để gửi thư rác hoặc sử dụng máy chủ của bạn để thiết lập một máy chủ web tạm thời, thường để phục vụ các tệp tin có tính chất bất hợp pháp. Các cách tấn công rất phổ biến này nhìn chung là nhằm mục đích lạm dụng các máy chủ bị xâm nhập, sử dụng chúng như một phần của một mạng botnet (mạng lưới các máy tính cá nhân bị nhiễm phần mềm độc hại và được điều khiển theo nhóm mà không hề biết, ví dụ như lợi dụng để gửi thư rác), hoặc mỏ cho Bitcoin. Thậm chí bạn có thể bị nhiễm ransomware - một loại phần mềm độc hại được thiết kế để chặn truy cập vào hệ thống máy tính cho đến khi một khoản tiền được trả.

Hacker thực hiện hack thường xuyên bằng các script tự động được viết để quét Internet nhằm cố gắng khai thác những vấn đề về bảo mật trang web đã biết trong phần mềm. Dưới đây là một số tip giúp bạn và trang web của bạn an toàn hơn trên mạng.

1. Keep software up to date (Cập nhật phần mềm thường xuyên)

Điều này có vẻ như là hiển nhiên, nhưng việc đảm bảo tất cả phần mềm được cập nhật là rất quan trọng trong việc giữ cho trang web của bạn an toàn. Điều này áp dụng cho cả hệ điều hành máy chủ và bất kỳ phần mềm nào đang chạy trên trang web của bạn, ví dụ như một CMS hoặc diễn đàn. Khi tìm thấy lỗ hổng bảo mật của trang web trong phần mềm, tin tặc nhanh chóng cố gắng lạm dụng chúng.

Nếu bạn đang sử dụng một giải pháp quản lý lưu trữ (hosting) thì bạn không cần phải lo lắng quá nhiều về việc áp dụng các bản cập nhật bảo mật cho hệ điều hành vì công ty hosting sẽ lo điều này.

Nếu bạn đang sử dụng phần mềm của bên thứ ba trên trang web của bạn ví dụ như một CMS hoặc diễn đàn, bạn nên đảm bảo rằng bạn có thể nhanh chóng áp dụng bất kỳ phần bảo mật nào. Hầu hết các nhà cung cấp đều có một danh sách gửi thư hoặc RSS feed nêu rõ bất kỳ vấn đề bảo mật nào trên trang web. WordPress, Umbraco và nhiều CMS khác sẽ thông báo cho bạn về những cập nhật hệ thống có sẵn khi bạn đăng nhập.

Nhiều developer sử dụng các tool như Composer, npm, hoặc RubyGems để quản lý các phụ thuộc phần mềm của họ, các lỗ hổng bảo mật có thể xuất hiện trong 1 package nào đó trong đây. Các lỗ hổng bảo mật nào đã bị công bố của hệ điều hành, máy chủ Web, máy chủ ứng dụng và các phần mềm của hãng thứ ba khác thì hầu hết đều có phần sửa lỗi bổ sung, tuy vậy những hệ thống không được cập nhật thường xuyên sẽ là miếng mồi ngon cho hacker. Chính vì vậy hãy luôn đảm bảo rằng phần mềm/ hệ thống của bạn được cập nhật thường xuyên, bạn cũng có thể sử dụng các tool thông báo tự động khi xuất hiện lỗ hổng bảo mật để kiểm soát lỗi, ví dụ như Gemnasium

2. SQL injection

SQL injection là một kỹ thuật cho phép những kẻ tấn công lợi dụng lỗ hổng của việc kiểm tra dữ liệu đầu vào trong các ứng dụng web và các thông báo lỗi của hệ quản trị cơ sở dữ liệu trả về để inject (tiêm vào) và thi hành các câu lệnh SQL bất hợp pháp (chèn các câu lệnh SQL bất hợp pháp vào 1 input field của form trên trang web hoặc vào param URL, nhằm mục đích truy cập hoặc thao tác trên cơ sở dữ liệu của bạn). SQL injection có thể cho phép những kẻ tấn công thực hiện các thao tác như một người quản trị web như delete, insert, update,… trên cơ sỡ dữ liệu của ứng dụng, thậm chí là server mà ứng dụng đó đang chạy. Lỗi này thường xảy ra trên các ứng dụng web có dữ liệu được quản lý bằng các hệ quản trị cơ sở dữ liệu như SQL Server, MySQL, Oracle, DB2, Sysbase…

SQL Injection là một trong những lớp ứng dụng phổ biến nhất tại các cuộc tấn công đang được sử dụng trên Internet. Mặc dù thực tế rằng tương đối dễ dàng để chống lại SQL Injection, nhưng vẫn có số lượng lớn các trang web đối mặt với nguy cơ bị tấn công injection.
Khi bạn sử dụng các câu giao dịch truy vấn chuẩn (standard Transact SQL) bạn sẽ rất dễ vô tình chèn các mã rogue vào truy vấn của bạn, các mã này có thể được sử dụng để thay đổi bảng, lấu thông tin và xóa dữ liệu trong DB. Bạn có thể dễ dàng phòng tránh điều này bằng cách sử dụng các câu truy vấn đã được tham số hóa (parameterised queries), hầu hết các ngôn ngữ lập trình web đều có tính năng này và dễ dàng sử dụng.

Do gần đây các khái niệm framework đã và đang được sử dụng rất nhiều. Các framework đều đã được test cẩn thận để phòng tránh các lỗi, trong đó có SQL Injection nên các lỗi SQL injection đã được giảm đi nhiều.

2.1. Ví dụ tấn công

Hãy xem truy vấn sau:

SELECT * FROM table WHERE column = '" + parameter + "';

Nếu kẻ tấn công thay đổi điều kiện truy vấn bằng cách thay param bằng OR '1'='1' để có 1 câu truy vấn luôn luôn đúng:

SELECT * FROM table WHERE column = ' ' OR '1'='1';

-Và nó sẽ còn tệ hại hơn khi mà người dùng chèn thêm một câu lệnh truy vấn phía sau:

SELECT * FROM table WHERE column = ' ' OR '1'='1'; Drop table users;

Các bạn nhìn vào thì đủ biết chuyện gì sẽ xảy ra đúng không nào.

2.2. Cách phòng chống

Cách phòng trống đối với dạng này thì cũng khá đơn giản. Các bạn chỉ cần ràng buộc thật kỹ dữ liệu người dùng nhập vào và luôn luôn phải có quan điểm 'Đừng bao giờ tin vào những thứ người dùng nhập vào là đúng'.

Luôn ràng buộc kiểu dữ liệu
Trong ứng dụng thì bạn luôn phải nhớ ràng buộc dữ liệu thật cẩn thận.
VD: Như đối với phương thức get url: http://domain.com?id=5.

//Thông thường
$id = $_GET['id'];
//Ràng buộc cẩn thận
$id = isset($_GET['id'])?(string)(int)$_GET['id']:false;

Regular Expression
Hoặc bạn có thể dùng Regular Expression để loại bỏ đi các ký tự lạ hoặc các ký tự cấm. Ví dụ trên:

$id = isset($_GET['id']) ? $_GET['id'] : false;
$id = str_replace('/[^0-9]/', '', $id);

Dùng các hàm có sẵn để giảm thiểu lỗi.
Mỗi khi truy vấn thì mọi người nên sử dụng thêm hàm mysqli_real_escape_string để chuyển đổi một chuỗi thành một query an toàn. Ví dụ:

$id = isset($_GET['id'])?(string)(int)$_GET['id']:false;
$sql= 'SELECT * FROM tbl_user WHERE id= ' . mysqli_real_escape_string($id);

Để đảm bảo tránh được 100% các lỗi liên quan đến SQL injection thì bạn nên sử dụng các framework thay vì code thuần.

3. XSS (Cross-Site Scripting)

Cross-site Scripting (XSS) là lỗ hổng bảo mật cho phép hacker có thể chèn những đoạn mã client-script (thường là Javascript hoặc HTML) vào trang web, khi người dùng vào những trang web này, mã độc sẽ được thực thi trên máy của người dùng (Nói cách khác XSS là một kỹ thuật tấn công buộc 1 trang Web phải hiển thị các đoạn mã độc, sau đó các mã này sẽ được thực thi trên trình duyệt web của người dùng nhờ vào mã javascript, nhằm mục đích thay đổi nội dung trang hoặc ăn cắp thông tin để gửi lại cho kẻ tấn công).
Khác với SQL Injection tấn công vào CSDL của website, XSS tấn công trực tiếp vào người dùng. Lợi dụng lỗi XSS, hacker có thể lừa đảo quản trị của website, ăn cắp cookie, chiếm sesion… từ đó có thể đăng nhập chiếm quyền điều khiển website.
Ví dụ : bạn có 1 bài đăng và các bình luận trong 1 trang web không có validation thì kẻ tấn công có thể vào gửi các bình luận có chứa các thẻ script hoặc các lệnh Javascript. Chúng có thể chạy khắp nơi trong trình duyệt của mọi người dùng khác và ăn cắp cookie đăng nhập của họ, cho phép cuộc tấn công kiểm soát tài khoản của tất cả những người dùng đã xem bình luận chứa mã độc đó.
Để ngăn chặn điều này, bạn cần đảm bảo rằng người dùng không thể đưa bất kỳ nội dung JavaScript nào vào các trang của bạn.

Đây là mối quan tâm đặc biệt trong các ứng dụng web hiện đại, nơi các trang được xây dựng chủ yếu từ nội dung người dùng và đa phần là HTML- sau này được thông dịch sang các framework front-end như Angular và Ember. Các framework này cung cấp nhiều biện pháp bảo vệ XSS, nhưng sự qua lại giữa máy chủ và client lại tạo ra các tuyến tấn công mới và phức tạp hơn : không đơn thuần chỉ là tiêm JavaScript vào HTML, mà còn có thể chèn nội dung sẽ chạy mã bằng cách chèn các chỉ thị Angular hoặc sử dụng Ember helpers.

Cách khắc phục :
Người ta không lường hết được mức độ nguy hiểm của XSS nhưng cũng không quá khó khăn để ngăn ngừa XSS. Giống như SQL Injection, bản chất của lỗi XSS là không kiểm soát kỹ dữ liệu nhập đầu vào, vì thế biện pháp hiệu quả nhất là kiểm tra kỹ dữ liệu nhập vào từ người dùng, chặn các từ khóa nguy hiểm, chỉ chấp nhận những dữ liệu hợp lệ.

Một trong những cách khác hay sử dụng mà không cần kiểm soát đầu vào từ người dùng là mã hoá các kí tự đặc biệt trước khi in ra website, nhất là những gì có thể gây nguy hiểm cho người sử dụng. Để phòng chống XSS tốt nhất là theo nguyên tắc FIEO (Filter Input, Escape Output). Để làm việc này thì hiện tại có khá nhiều bộ lọc để chúng ta lựa chọn. Ví dụ bộ thư viện viết bằng PHP cho phép filter HTML để ngăn chặn kẻ xấu post mã độc XSS thông qua website của bạn.

  • Viết mã lọc nội dung theo nguyên tắc FIEO (Filter Input, Escape Output) - vì các đoạn mã độc bắt đầu với “<script>” và kết thúc với “</script>” . Thay : “<” và “>” = “>” và “<” (các thực thể html) như vậy nó sẽ vẫn được in ra màn hình đúng định dạng mà không hề gây nguy hiểm cho người sử dụng.Ta có đoạn code sau :
str_replace("<",">",$info);str_replace(">","<",$info);str_replace("'","&apos;",$info);str_replace(""",""",$info);
str_replace("&","&",$info);  
  • Mã hóa các ký tự đặc biệt của HTML với hàm htmlentities()
include("../../connect.php");
$query = "select * from message order by time desc";
$result = mysql_query($query);
$numRow = mysql_num_rows($result);
if ($numRow != 0){
 while($row = mysql_fetch_array($result))
 echo $row["content"];
}

Ta thấy ở đoạn code trên biến $row["content"] được in trực tiếp ra mà không qua xử lý. Trường content được nhập vào từ người dùng nên đoạn code này chắc chắn có lỗi XSS. Để khắc phục ta sẽ mã hóa các ký tự đặc biệt của HTML với hàm htmlentities(). Mã nguồn được chỉnh sửa lại như sau:

echo htmlentities($row["content"]);

  • Dùng thư viện có sẵn : HTML Purifier
    Nói sơ qua về HTML Purifier thì đây là bộ thư viện rất mạnh dùng triển khai trong code để chống XSS. Được xây dựng theo mô hình OOP nên sử dụng rất dễ, sau thao tác include file thư viện, chỉ cần tạo instance của đối tượng HTML Purifier và gọi phương thức purify() là có thể filter được dữ liệu đầu vào.
phprequire_once '/path/to/htmlpurifier/library/HTMLPurifier.auto.php';$purifier = new HTMLPurifier();$clean_html = $purifier->purify($dirty_html);

4. Error messages (Thông báo lỗi)

Hãy cẩn thận với lượng thông tin bạn đưa ra trong các thông báo lỗi của mình. Chỉ nên cung cấp lỗi nhỏ cho người dùng, để đảm bảo rằng họ không làm rỏ rỉ bí mật trên máy chủ của bạn (ví dụ như các key API hoặc các password của DB). Không cung cấp đầy đủ chi tiết ngoại lệ vì những điều này có thể làm cho các cuộc tấn công phức tạp như SQL injection trở nên dễ dàng hơn. Giữ các lỗi chi tiết trong nhật ký server và chỉ cung cấp cho user thông tin họ cần.

5. Server side validation/form validation

Validation nên được thực hiện ở cả bên trình duyệt (validate dưới client/user - UI) và server side (server). Phía trình duyệt có thể bắt các lỗi đơn giản như bỏ trống ở các trường bắt buộc hoặc nhập văn bản vào một trường yêu cầu số. Tuy nhiên có thể vẫn sẽ bỏ sót lỗi (mã độc pass), vì vậy bạn cần phải thực hiện validation sâu hơn ở phía máy chủ vì không thực hiện như vậy có thể dẫn đến mã độc hại hoặc mã kịch bản được chèn vào cơ sở dữ liệu hoặc có thể gây ra các kết quả không mong muốn trong trang web của bạn. Tuy vậy, việc đã thực hiện validation ở bên trình duyệt trước rồi cũng sẽ giảm tải công việc cho bên server.

6. Password

Ai cũng biết là nên sử dụng mật khẩu phức tạp thì sẽ bảo mật tốt hơn nhưng không phải ai cũng làm điều đó. Sử dụng mật khẩu mạnh (strong password) ở server và admin là điều rất quan trọng nhưng việc sử dụng mật khẩu mạnh cho người dùng cũng quan trọng không kém để bảo mật tài khoản người dùng được tốt hơn. Nhiều người dùng có thể không thích strong password này vì nó gây ra sự khó khăn trong việc đăng ký hoặc khó để nhớ nhưng mà nó sẽ giúp bảo vệ thông tin trong thời gian dài. Một số yêu cầu có thể gặp để có được 1 strong password : phải lớn hơn hoặc bằng 8 ký tự, có ít nhất 1 chữ in hoa, có ít nhất 1 chữ số, có ít nhất 1 ký tự đặc biệt, bắt đầu bằng ký tự đặc biệt ....

Mật khẩu phải luôn được lưu trữ dưới dạng các giá trị đã được mã hóa, tốt hơn cả là sử dụng thuật toán hàm băm (hash) một chiều như SHA. Sử dụng phương pháp này có nghĩa là khi bạn xác thực người dùng, bạn chỉ cần so sánh các giá trị được mã hóa. Để bảo mật trang web tốt hơn, bạn nên hash password bằng salt để khắc phục weak password. Người dùng có thể chọn một mật khẩu yếu, đó là chuyện bình thường. Tuy nhiên, là người xây dựng hệ thống các bạn cần phải khắc phục điều này. Giải pháp là sử dụng thêm một chuỗi mà thường được gọi là salt.
Hiểu đơn giản như thế này : trong cấu hình của ứng dụng, các bạn lưu trữ một chuỗi (phức tạp dài dòng) được gọi là salt. Trước khi lưu trữ mật mã vào cơ sở dữ liệu chúng ta thực hiện việc kết hợp salt với mật mã. Có nhiều kiểu kết hợp khác nhau, đơn giản nhất là nối chúng lại (ví dụ với PHP):

$crypPassword = md5($rawPassword.$salt);

Sau đó mật mã mới này được lưu vào cơ sở dữ liệu. Khi đó, dù ai đó có toàn bộ dữ liệu của chúng ta cũng không dễ dàng để dò ra mật khẩu dựa vào weak password dictionary được.
Ngoài ra, có thể làm cho hệ thống tốt hơn bằng việc sử dụng salt duy nhất cho mỗi mật mã. Thông thường hệ thống sẽ có rất nhiều thành viên, và việc các thành viên dùng mật khẩu giống nhau là phổ biến. Hãy đặt tình huống hacker có cả hai thông tin là dữ liệu và salt. Nếu chúng ta sử dụng một salt duy nhất, khi ấy tất cả các tài khoản dùng chung mật mã thì mật mã được mã hóa (crypPassword) đều sẽ giống nhau. Kẻ tấn công sẽ chỉ cần brute force một trong số đó là cũng có các tài khoản còn lại mà không tốn thêm công sức gì. Để tránh rủi ro này và làm tăng thêm khó khăn cho kẻ tấn công, hệ thống nên sử dụng các salt duy nhất cho mỗi mật mã. Lúc ấy, mỗi crypPassword sẽ là khác nhau và tất nhiên hacker sẽ không có được danh sách các tài khoản có mật mã giống nhau. Trường hợp xấu nhất là một kẻ tấn công nào đó sẽ làm một cuộc tấn công bằng từ điển hoặc tấn công brute force, về cơ bản nó sẽ đoán (dò) mọi sự kết hợp cho đến khi nó tìm thấy một match (kết quả). Hacker sẽ phải brute force từng tài khoản một -> rất khó khăn cho việc tính toán + dò mật khẩu.
Có nhiều cách để tạo salt độc nhất. Việc này sẽ dễ dàng nếu bạn có kiến thức về các hàm entropy trong ngôn ngữ lập trình đang dùng.

Nhiều CMS cung cấp cho người dùng quản lý với rất nhiều tính năng bảo mật trang web đã được xây dựng bên trong nó, mặc dù một số module cấu hình hoặc module mở rộng có thể được yêu cầu sử dụng password đã được salt hoặc đã thiết lập mật khẩu mạnh tối thiểu. Nếu bạn đang sử dụng .NET, bạn nên sử dụng các nhà cung cấp thành viên vì cấu hình của chúng có sẵn bảo mật trang web và cung cấp các điều khiển readymade để đăng nhập và đặt lại mật khẩu.

7. File uploads

Cho phép người dùng tải file lên trang web của bạn có thể là nguy cơ gây rủi ro lớn cho bảo mật trang web, ngay cả khi chỉ là tính năng đơn giản như thay đổi avatar của người dùng. Rủi ro ở đây là có tệp tin nào đó được tải lên nhìn tưởng chừng như vô hại nhưng có thể có thể chứa một script mà khi thực hiện trên máy chủ sẽ mở ra trang web của bạn. Ví dụ như : khi người dùng của bạn tải lên 1 file ảnh, bạn không thể chỉ dựa vào extension hoặc mime type của file đó để xác minh rằng file đó là một file ảnh vì chúng có thể dễ bị giả mạo. Thậm chí ngay cả khi bạn mở tệp tin và đọc phần header hoặc sử dụng các hàm kiểm tra kích thước ảnh thì cũng không phải là bằng chứng đầy đủ. Hầu hết các định dạng ảnh đều cho phép lưu trữ một phần comment, phần comment này có thể sẽ chứa mã độc và được thực hiện trên server.

Vậy làm sao để ngăn chặn điều này?
Theo mặc định, các máy chủ web sẽ không thực thi các file có extension là ảnh nhưng cũng không nên chỉ dựa vào việc kiểm tra phần extension của file. Một số tùy chọn là đổi tên tệp khi tải lên để đảm bảo phần extension của tệp là chính xác hoặc để thay đổi quyền truy cập tệp, ví dụ chmod 0666 do đó không thể thực hiện được. Nếu sử dụng *nix bạn có thể tạo tệp tin .htaccess sẽ chỉ cho phép truy cập vào tập các file, ngăn chặn cuộc tấn công extension kép được đề cập trước đó.

deny from all
    <Files ~ "^\w+\.(gif|jpe?g|png)$">
    order deny,allow
    allow from all
    </Files>

Nên lưu trữ các ảnh được tải lên ở một thư mục bên ngoài webroot hoặc trong cơ sở dữ liệu dưới dạng blob. Không thể truy cập trực tiếp tới các file này, bạn cần phải tạo một script để fetch từ thư mục riêng (hoặc trình xử lý HTTP trong .NET) và đưa chúng tới trình duyệt. Các thẻ ảnh hỗ trợ thuộc tính scr chứ không phải là URL trực tiếp vào image, src có thể trỏ đến tập lệnh phân phối tập tin của bạn, cung cấp cho bạn đặt đúng loại nội dung trong tiêu đề HTTP. Ví dụ:

<img src="/imageDelivery.php?id=1234" />
     
<?php
      // imageDelivery.php
     
      // Fetch image filename from database based on $_GET["id"]
      ...
     
      // Deliver image to browser
       Header('Content-Type: image/gif');
      readfile('images/'.$fileName);  
     
?>

Hầu hết các nhà cung cấp dịch vụ lưu trữ đều phải cấu hình máy chủ cho bạn, nhưng nếu bạn đang lưu trữ trang web của bạn trên máy chủ của riêng bạn thì có vài điều bạn sẽ muốn kiểm tra. Đảm bảo rằng bạn có một thiết lập tường lửa, và đang chặn tất cả các cổng không cần thiết. Nếu có thể thiết lập DMZ (Demilitarised Zone) chỉ cho phép truy cập vào cổng 80 và 443 từ thế giới bên ngoài. Mặc dù điều này có thể không khả thi nếu bạn không có quyền truy cập vào máy chủ của mình từ mạng nội bộ vì bạn cần phải mở cổng để cho phép tải tệp lên và đăng nhập từ xa vào máy chủ của bạn qua SSH hoặc RDP.

Nếu bạn cho phép các tệp được tải lên từ Internet thì chỉ nên sử dụng các phương thức truyền tải an toàn đến máy chủ của bạn như SFTP hoặc SSH.
Nếu cơ sở dữ liệu của bạn đang chạy trên một máy chủ khác với máy chủ web của bạn. Làm điều này có nghĩa là không thể truy cập trực tiếp máy chủ cơ sở dữ liệu từ thế giới bên ngoài, chỉ có máy chủ web của bạn có thể truy cập vào nó, giảm thiểu nguy cơ dữ liệu của bạn bị lộ. Cuối cùng, đừng quên giới hạn quyền truy cập vào máy chủ của bạn.

8. HTTPS

HTTPS là một giao thức được sử dụng để cung cấp bảo mật qua Internet. HTTPS đảm bảo với người dùng rằng họ đang nói chuyện với máy chủ họ mong đợi và không ai khác có thể đánh chặn hoặc thay đổi nội dung mà họ đang nhìn thấy khi chuyển tiếp.
Nếu có bất cứ thứ gì mà người dùng của bạn muốn riêng tư, bạn chỉ nên sử dụng HTTPS để phân phối nó. Tất nhiên điều này có nghĩa là áp dụng cho thẻ tín dụng và các trang đăng nhập (và URL mà họ gửi đến). Ví dụ một form đăng nhập thường sẽ thiết lập một cookie sẽ được gửi cùng với mọi yêu cầu khác đến trang của bạn mà người dùng đăng nhập tạo ra và được sử dụng để xác thực các yêu cầu đó. Một kẻ tấn công ăn cắp được thông tin này sẽ có thể bắt chước (giả mạo) người dùng một cách hoàn hảo và tiếp quản phiên đăng nhập của họ. Để đánh bại các loại tấn công này, bạn hầu như luôn muốn sử dụng HTTPS cho toàn bộ trang web của mình.
Điều đó không còn khó khăn và tốn kém như trước nữa. Hãy để Encrypt cung cấp các xác nhận hoàn toàn miễn phí và tự động, bạn sẽ cần HTTPS, các tool cộng đồng hiện có sẵn cho một loạt các nền tảng và framework chung để tự động thiết lập điều này cho bạn.

9. Website security tools

Bận có thể bảo mật cho trang web của mình bằng cách sử dụng một số tool bảo mật trang web. Có rất nhiều sản phẩm thương mại và miễn phí để giúp bạn việc này. Chúng hoạt động trên cơ sở tương tự như các tập lệnh mà các hacker sử dụng để kiểm tra tất cả các hành vi khai thác và cố gắng thỏa hiệp trang web của bạn bằng cách sử dụng một số phương pháp đã đề cập trước đó chẳng hạn như SQL injection.
Một số tool miễn phí như:

  • Netsparker : tốt cho kiểm tra SQL injection và XSS
  • OpenVAS
  • SecurityHeaders.io (free online check)
  • Others

Lời kết

Còn rất nhiều các loại tấn công khác và các cách phòng chống khác nhau mà không đề cập trong bài. Có gì thiếu sót mong mọi người góp ý thêm (yeah)

Link tham khảo

Categories

Recent posts