Bảo mật những trang web .aspx của bạn bằng Forms là cách rất đơn giản và hữu hiệu. So với ASP thì ASP.NET làm một website mà người sử dụng phải đăng nhật vào mới xem được khá đơn giản. Tất cả mọi sự kiểm tra về user đều năm trong web.config file. Khi đã đăng nhập thì chúng ta có thể quyết định được muốn cho user đó xem nhưng gì, cũng chỉ từ web.config.

Trong ASP thì thường là chúng ta tạo session cho user đó khi họ đã đăng nhập thành công và trên đầu mỗi trang asp ta phải có một hang kiểm tra xem session của người đó có đúng không, như vậy có nghĩa là mỗi khi ta làm một trang web mới ta phải nhớ đặt hang kiểm tra đo, trong khi ASP.NET ta không cần phải nghi đến điều đó.

2 chữ cần biết trong web.config:

Authentication và Authorization

Kiểm tra User khi mở một trang web của bạn thì trong ASP.NET trước hết là Internet Information Server (IIS) kiểm tra trước xong mới gởi đến cho ASP.NET. Có thể hiểu là IIS kiểm tra bảo mật của website còn ASP.NET kiểm tra User đó được phép xem nhưng nơi nào trong website. Nếu trang web mà user muốn xem nằng trong danh sách mà user này có quyền xem thi ASP.NET sẽ gởi cho user, nếu không sẽ chuyển đến trang login

user posted image

CODE

<!-- AUTHENTICATION

This section sets the authentication policies of the application. Possible modes are "Windows",

"Forms", "Passport" and "None"

"None" No authentication is performed.

"Windows" IIS performs authentication (Basic, Digest, or Integrated Windows) according to

its settings for the application. Anonymous access must be disabled in IIS.

"Forms" You provide a custom form (Web page) for users to enter their credentials, and then

you authenticate them in your application. A user credential token is stored in a cookie.

"Passport" Authentication is performed via a centralized authentication service provided

by Microsoft that offers a single logon and core profile services for member sites.

-->

<!-- enable Forms authentication -->

<authentication mode="Windows" />

<!-- AUTHORIZATION

This section sets the authorization policies of the application. You can allow or deny access

to application resources by user or role. Wildcards: "*" mean everyone, "?" means anonymous

(unauthenticated) users.

-->

<authorization>

trong web.config tag authentication có 3 mode chúng ta có thể sử dụng: Forms, Passport và Windows.

Forms: dung cookie

Passport: dung Microsoft Passport

Windows: dùng bảo mật của Windows. User name phải có trong windows server.

Nếu chúng ta tự viết cách bảo mật riêng thì dùng “NONE”.

Dùng Forms-Authentication

Dùng form là cách thong dụng nhất. Khi dùng Forms thì chỉ cần viết Froms, Passport họac Windows trong mode như thí dụ sau:

CODE

<authentication mode="Forms">

<forms name="CookieName" loginUrl="Login.aspx" protection="All" path="/" timeout="1">

<credentials passwordFormat="Clear">

<user name="dott" password="dott" />

<user name="demo" password="2004" />

</credentials>

</forms>

</authentication>

<authorization>

<deny users="?" />

</authorization>

Name: là tên của HTTP cookie.

LoginURL: là trang web mà user phải đăng nhập với user name và password. Nếu user chưa đăng nhập mà mở một trang web thì ASP.NET sẽ gọi trang trong loginURL, trong trường hợp này là Login.aspx.

Protection = “None”: dùng cookie không được mã hóa

“Encryption”: mã hóa cookie dùng Triple DES họac DES,

“Validation”: không mã hóa nhưng bảo vệ cookie không bị thay đổi.

Timeout: là thời gian không họat đông của user trước khi server xóa cookie và session. Và user phải login lại nếu muốn đoc những trang trong website.

[b]Path=”/”: có nghĩa tất cả từ chỗ login.aspx, hay là root của webstie, ở đây chúng ta cũng có thể đề tên thư mục mình muốn bảo vệ.

2. Khi user chưa đăng nhập mà mở một trang web thì ASP.NET sẽ chuyển đến trang trong loginURL ở Authentication tag. Trang trong loginURL sẽ là trang để user đăng nhập.

Tôi làm 2 users trong authentication tag như sau:

CODE

<credentials passwordFormat="Clear">

<user name="dott" password="dott" />

<user name="demo" password="2004" />

</credentials>

trong trang web login chúng ta sẽ dùng dữ liệu về username và password nằm trong đây. Đây là một cách đơn giản tạo user nếu bạn không có csdl, nhưng cách này về bảo mật không cao. Nên dùng csdl để chứa những thong tin như thế này.

LÀM TRANG LOGIN

CODE

<%@ Import Namespace="System.Web.Security " %>

<HTML>

<script language="C#" runat="server">

void Login_Click(Object sender, EventArgs E)

{

if (FormsAuthentication.Authenticate(txtUserName.Value, txtPass.Value))

{

// dang nhap thanh cong, chuyen den trang web user muon xem

FormsAuthentication.RedirectFromLoginPage(txtUserName.Value, nhocookie.Checked);

}

else

{

lblResults.Text = "Đăng nhập sai";

}

}

</script>

<body bgColor="seashell">

<form runat="server" ID="Form1">

<h3>Đăng Nhập</h3>

<hr>

Tên:<input id="txtUserName" type="text" runat="server" NAME="txtUserName">

<asp:RequiredFieldValidator ControlToValidate="txtUserName" Display="Static" ErrorMessage="*" runat="server"

ID="Requiredfieldvalidator1" NAME="Requiredfieldvalidator1" />

<p>Mã:<input id="txtPass" type="password" runat="server" NAME="txtPass">

<asp:RequiredFieldValidator ControlToValidate="txtPass" Display="Static" ErrorMessage="*" runat="server" ID="Requiredfieldvalidator2"

NAME="Requiredfieldvalidator2" />

<p>Nhớ Tôi:<ASP:CheckBox id=" nhocookie " runat="server" />

<p><asp:button id="cmdLogin" text="Login" OnClick="Login_Click" runat="server" />

<p><asp:Label id="lblResults" ForeColor="red" Font-Size="10" runat="server" />

</form>

</P>

</body>

</HTML>

FormsAuthentication.Authenticate(txtUserName.Value, txtPass.Value)

Hàng này sẽ kiểm tra dữ liệu user điền vào với dữ liệu trong web.config. Nếu đúng sẽ cho phép user đăng nhập và trang web mà họ mở trước khi được phép.

Thí dụ bạn mở trang ten web.aspx nhưng chưa được phép, ASP.NET bắt bạn phải đăng nhập. khi bạn đăng nhập xong bạn sẽ mở được trang web đó. ASP.NET nhớ bạn đã mở trang nào trước khi đăng nhập.

FormsAuthentication.RedirectFromLoginPage(txtUserName.Value, nhocookie.Checked);

Một cách khác nếu bạn muốn dẫn user đến một trang web bạn muốn thì có thể đăng nhập user bằng:

FormsAuthentication.SetAuthCookie(txtUserName.Value, nhocookie.Checked);

Sau đó Response.Redirect (“trangweb.aspx”);

Khi "Nhớ Tôi" được bấm thì Cookie không bị xóa, lần sau bạn không cần phải login nữa. Sau một thời gian nhất định Cookie sẽ tự động bị xóa.

Ngày nay, sự đe dọa lớn nhất đối với an ninh của các mạng máy tính của các tổ chức lại đến từ chính các Website công cộng và các ứng dụng đặt ở trên các web của họ. Không giống như các dịch vụ dùng trong mạng cục bộ như là các cơ sở dữ liệu có thể ngăn cản sự truy cập từ bên ngoài thông qua firewalls, thì mọi người đều có thể truy cập vào một trang web công cộng, khiến cho các ứng dụng bảo mật gặp nhiều vấn đề. Khi mà các hệ thống mạng đang trở nên kiên cố hơn, các file có khả năng bảo mật thấp trong các ứng dụng web càng thu hút được sự chú ý của các hacker, bao gồm cả những người chỉ muốn tiêu khiển và cả những tên trộm, những kẻ luôn có các công nghệ đủ để khai thác các lỗ hổng đó. Việc tấn công này có thể gây các nguy hại đến cho các hệ thống mạng.

Đã có một vài phần mềm và một số người phát triển được đào tạo để tạo ra các phần mềm bảo mật hay thiết kế các ứng dụng web có khả năng tự bảo vệ cao. Bằng cách "baking in" an ninh của các ứng dụng ngay từ đầu quá trình phát triển thay cho "brush it on" sau khi đã hoàn thành, bạn sẽ dễ dàng tạo ra các ứng dụng bảo mật có thể chống lại sự tấn công của hackers. Tuy nhiên, ngay cả những mã nguồn bảo mật được viết tỉ mỷ nhất trên C# hay VB.NET vẫn có thể bị nguy hại nếu bạn không quan tâm đến các file cấu hình trong Web.config của ứng dụng. Các ứng dụng mạng cơ bản được cấu hình không hợp lý có thể bị nguy hiểm giống như được code không chính xác. Các vấn đề còn tồi tệ hơn, khi mà nhiều thiết lập cấu hình hiện nay thường để default và khi đó các giá trị thường là không an toàn.

Ở đây chúng ta sẽ nói về những lỗi hay tồi tệ nhất trong file cấu hình có thể gây hại đến cho các ứng dụng của chúng ta.

1. Custom Errors Disable: ASP.NET sẽ đưa ra một bản thông báo chi tiết các lỗi tới người dùng khi bạn vô hiệu các lỗi đã được mặc định như dưới đây:

Cấu hình có thể bị gây hại:

Trích:

<configuration>

<system.web>

<customErrors mode="Off">

Cấu hình có khả năng bảo vệ :

Trích:

<configuration>

<system.web="RemoteOnly">

Việc hiểu được nguồn gốc các lỗi thì tự nó không gây hại gì cho khả năng bảo mật của ứng dụng nhưng hãy chú ý là: một hacker càng có nhiều thông tin về một website thì chúng càng có nhiều khả năng tấn công nó. Một thông báo lỗi có thể trở thành một mỏ vàng các thông tin cho những kẻ tấn công. Một thông báo lỗi liệt kê các phiên bản đặc trưng của các framework ASP.NET và .NET có thể được sử dụng bởi các web server, cũng giống như việc bắt các exception vậy. Chỉ cần biết các ứng dụng web cơ bản nào được dùng(trường hợp dùng ASP.NET) sẽ cho kẻ tấn công biết rẳng server đang chạy một phiên bản Microsoft Windows nào cũng như sử dụng web server là Microsoft Internet Information Server(IIS) 6.0 hay cao hơn. Lỗi này cũng giúp cho các hacker biết được cấu hình của các ứng dụng web đó; chẳng hạn như, nếu một "SqlException" được bắt, thì kẻ tấn công sẽ biết được rằng ứng dụng đang sử dụng một trong phiên bản của Microsoft SQL Server.

Bạn có thể xây dựng các ứng dụng có khả năng bảo mật để ngăn cản sự rò rỉ thông tin bằng cách điều chỉnh các đặc tính của thành phần <customErrors> sang "On" hoặc là "RemoteOnly". Cách thiết lập này sẽ báo cho ứng dụng chỉ hiển thị thông báo lỗi chung chung và khó nhận biết khi có lỗi nào đó được sinh ra. Một cách khác để tránh các vấn đề bảo mật ứng dụng là redirect người dùng đến một trang mới khi có lỗi xảy ra bằng cách thiết lập "defaultRedirect" trong <customErrors>. Cách này sẽ giúp cho các ứng dụng khả năng bảo mật cao hơn bởi vì các trang lỗi chung mặc định sẽ không để lộ nhiều thông tin về hệ thống(đây là trường hợp server sử dụng ASP.NET ).

2.Leaving tracing enabled in web-based applications:trace là một trong những tool hứuich nhất trong ASP.NET, nó giúp bạn có thể đảm bảo tính bảo mật cho các ứng dụng. Thật không may, nó

cũng là một trong những tool mà các hacker lợi dụng nhiều nhất để tấn công vào ứng dụng của bạn nếu nó được cho phép trong sản phẩm(cho phép người dùng tác động vào).

Cấu hình có nguy cơ bị tấn công cao :

Trích:

<configuration>

<System.web="true"localOnly="false">

Cấu hình có khả năng bảo mật:

Trích:

<configuration>

<system.web="false" localOnly="true">

Khi <trace> đặt ở chế độ cho phép người dùng điều khiển(localOnly="false"), bất cứ người dùng nào cũng có thể xem chi tiết danh sách các yêu cầu gần đây đối với ứng dụng bằng cách rất đơn giản là vào trang "trace.axd". Nếu một thông báo chi tiết lỗil là một mỏ vàng đối với các hacker thì việc truy cập được vào trace lại giống như Fort Knox! Truy cập vào trace cho biết rất nhiều thông tin: các phiên bản .NET và ASP.NET mà server đang chạy; một liệt kê đầy đủ các phương thức do các yêu cầu sinh ra, bao gồm cả thời gian thực hiệnl; trạng thái các phiên và các key trạng thái của ứng dụng; các cookies đáp ứng và yêu cầu; thiết lập đầy đủ các yêu cầu headers, các biến hình thức, và các biến QueryString; và cuối cùng là thiết lập đầy đủ các biến server.

Một hacker luôn tìm kiếm cách để biết được lịch sử cách sử dụng các biến hình thức bởi vì những điều này có thể bao gồm cả các địa chỉ email, điều đó sẽ giúp chúng có thể bán lại cho các kẻ gửi thư rác, ID và password có thể bị sử dụng để mạo nhận người dùng, hoặc các thông tin về tài khoản ngân hàng hay thẻ tín dụng có thể bị đánh cắp. Thậm chí là những dữ liệu có vẻ như vô hại nhất trong trace cũng có thể gây nguy hiểm nếu rơi vào tay kẻ xấu. Ví dụ, biến server "APPL_PHYSICAL_PATH", bao gồm các đường dẫn vật lý của các ứng dụng web trên server, có thể giúp các hacker tìm được các đường dẫn tới các thư mục tấn công lại hệ thống.

Cách tốt nhất để ngăn cản 1 hacker đạt được các dữ liệu trong trace từ các ứng dụng web là không cho phép xem trace bẳng cách thiết lập đặc tính "enabled" của <trace> sang "false". Nếu bạn bắt buộc phải để trace ở "enabled" thì hãy chắc chắn rằng để "localOnly" ở "true". Điều đó khiến người dùng chỉ có thể xem trace ở trên web server và vô hiệu việc xem từ các máy từ xa, tăng khả năng bảo vệ cho ứng dụng của bạn.

3. Cho phép debug:

Triển khai các ứng dụng web ở chế độ debug là một sai lầm rất phổ biến. Hầu như các ứng dụng web đều đòi hỏi phải debug. Visual Studio 2005 thậm chí còn tự động điều chỉnh Web.config cho phép debug khi bạn bắt đầu debug ứng dụng của bạn. Và, khi triển khai ứng dụng ASP.NET đơn giản như copy các file từ các thư mục phát triển sang các thư mục triển khai, thì cũng rất dễ dàng nhận ra các thiết lập cấu hình có thể gặp sai lầm bao gồm cả các lỗi bảo mật .

Cấu hình có lỗi :

Trích:

<configuration>

<system.web>

<compilation debug="true">

Cấu hình đúng:

Trích:

<configuration>

<system.web>

<compilation debug="false">

Giống như 2 lỗi trên việc cho phép debug rất nguy hiểm bởi người dùng hoàn toàn có thể thu được các thông tin bên trong hệ thống của bạn qua đó tấn công ứng dụng của bạn. Thật không may là thiết lập này không phải là lỗi duy nhất, điều đó giải thích tại sao những người phát triển phần mềm không nên chú trọng vào một cấu hình duy nhất khi muốn bảo đảm tính bảo mật của hệ thống. Trong các phiên bản framework đầu tiên, một vài điều khiển trả về các thông báo tới người dùng khi có lỗi. Điều này xảy ra cho dù có thiết lập debug hay ko, vì thế cho dù bạn hoàn toàn có thể cấu hình ứng dụng của mình chỉ hiển thị các thông tin không quan trọng thì source code của bạn vẫn có thể rơi vào tay người dùng nếu bạn vẫn cho phép debug.

Để vô hiệu debug, đặt giá trị của "debug" trong <compilation> bằng "false". Đây là giá trị mặc định nhưng chúng ta nên tự cấu hình lại chứ không nên phụ thuộc vào cấu hình mặc định để bảo đảm tính bảo mật cho hệ thống.

4.Có thể truy cập cookies từ các script của phía client :

Trong trình duyệt IE 6.0, Microsoft đã giới thiệu đặc tính cookie mới gọi là "HttpOnly". Trong khi bạn có thể thiết lập các đặc tính chương trình trên một nền tảng của mối cookie, bạn vẫn có thể thiết lập nó trên toàn cầu trong một trang cấu hình.

Bất kỳ cookie nào đặt ở đặc tính này đều chỉ có thể được truy nhập vào từ các code ở trên server.Điều này giúp nâng cao tính bảo mật cho hệ thống của bạn. Các hacker đều thuộc lòng cách tấn công CSS (Cross-Site Scripting, còn gọi là XSS) để thêm vào các mã nguồn riêng của mình. Khi đó thì tính bảo mật của hệ thống sẽ bị đe dọa nghiêm trọng. Các forum, wiki thường hay mắc phải các lỗi này. Trong những trang này, các người dùng hợp pháp post lên những suy nghĩ, ý tưởng của họ , những điều này là hoàn toàn public với tất cả mọi người xem trang web. Nhưng một kẻ tấn công thì sẽ post lên những bản tin như kiểu "<script>alert(document.cookie);</script>". Thông tin này bao gồm các script của anh ta và sẽ được trình duyệt biên dịch và chạy. Những thông tin này thường nhằm mục đích lấy các thông tin truy cập của người dùng để sử dụng vào các mục đích xấu. Nếu đặt các cookie ở "HttpOnly" sẽ giúp các thông tin này không thể thấy được từ phía client và sẽ ngăn cản được việc bị tấn công. Vì thế hãy thiết lập "HttpOnly" của "HttpCookie" ở giá trị "true ". Tuy nhiên có một cách còn đơn giản và đáng tin cậy hơn là cấu hình cho hệ thống tự động cho phép "HttpOnly" cho tất cả các cookie. Chỉ cần đặt "HttpOnlyCookies " của thành phần <httpCookies> thành "true".

Một trong những vấn đề cần quan tâm khi sử dụng Web Service đó chính là vấn đề bảo mật và quản lý tài khoản truy cập. Do Web Service được đặt trên Web Server, và có thể được truy cập thông qua Internet nên cần phải có cơ chế kiểm soát quyền truy cập và thực hiện. Bài này sẽ giới thiệu một số kỹ thuật sử dụng trong vấn đề bảo mật cho Web Service.

Quản lý tài khoản và phân quyền

ASP.NET cung cấp sẵn chức năng quản lý tài khoản và phân quyền thông qua thư việc System.Web.Security, trong đó lớp Membership quản lý các tài khoản và lớp Roles quản lý quyền và phân quyền. Các tài khoản có thể được tạo ra thông qua các trang quản trị hoặc dùng Web Service. Thông tin về các tài khoản được lưu trong một CSDL SQL Server có tên ASPNETDB.MDF (ngầm định).

Thiết lập quyền truy cập và sử dụng Web Service

Web Service cũng như Web Page, một số cho phép truy cập tự do, một số yêu cầu phải có quyền truy cập. Việc thiết lập quyền truy cập một Web Service được thực hiện như đối với Web Page, và thường được cấu hình trong web.config. Đoạn mã sau thiết lập quyền truy cập Administrators cho tất cả các trang trong thư mục admin:

<location path="Admin">

<system.web>

<authorization>

<allow roles=”Administrators”/>

<deny users=”*”/>

</authorization>

</system.web>

</location>

Tuy nhiên cách thiết lập này thường được áp dụng đối với Web Page, còn đối với Web Service thường cho phép truy cập tự do nhưng thiết lập quyền thực hiện đối với từng phương thức. Để thiết lập quyền thực hiện phương thức, thêm thuộc tính PrincipalPermission và quy định quyền tương ứng.

Đối với những phương thức chỉ yêu cầu đăng nhập, không cần quan tâm đến nhóm, thì đặt Authenticated = true. Ví dụ để thực hiện phương thức GetCategories, chỉ cần đăng nhập thành công:

[WebMethod]

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]

public DiscountDataSet.CategoriesDataTable GetCategories() {

return new DiscountDataSetTableAdapters.CategoriesTableAdapter().GetData();

}

Các phương thức cần thiết lập các quyền cụ thể, thì ứng với mỗi quyền đặt một thuộc tính PrincipalPermission. Ví dụ để thực hiện phương thức UpdateCategories, cần phải có quyền Administrators hoặc Editors, định nghĩa phương thức đó như sau:

[WebMethod]

[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]

[PrincipalPermission(SecurityAction.Demand, Role = "Editors")]

public void UpdateCategories(DiscountDataSet.CategoriesDataTable categories) {

new DiscountDataSetTableAdapters.CategoriesTableAdapter().Update(categories);

}

Để có thể sử dụng các phương thức có thiết lập quyền thực hiện, cần phải đăng nhập với quyền tương ứng. Phương thức đăng nhập có thể được định nghĩa như sau:

[WebMethod]

public bool LogIn(string userName, string password) {

if (System.Web.Security.Membership.ValidateUser(userName, password)) {

FormsAuthentication.SetAuthCookie(userName, true);

return true;

} else {

return false;

}

}

Ở đây, việc kiểm tra tính hợp lệ của tài khoản được thực hiện bằng phương thức ValidateUser của Membership và đặt trạng thái đăng nhập bằng phương thức SetAuthCookie của FormsAuthentication. Để trạng thái đăng nhập được lưu lại phục vụ cho việc thực hiện các phương thức khác, phía client phải bật Cookie. Phương thức đăng xuất được định nghĩa như sau:

[WebMethod]

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]

public void LogOut() {

if (Context.User.Identity.IsAuthenticated)

FormsAuthentication.SignOut();

}

Sau khi đăng xuất, trạng thái đăng nhập bị xoá và để thực hiện được các phương thức có thiết lập quyền thì phải đăng nhập trở lại.

Để xác định trạng thái đăng nhập hiện thời, hoặc xem tài khoản đăng nhập hiện thời có nằm trong nhóm nào đó hay không, có thể định nghĩa các phương thức sau:

[WebMethod]

public bool IsAuthenticated() {

return Context.User.Identity.IsAuthenticated;

}

[WebMethod]

public bool IsInRole(string role) {

return System.Web.Security.Roles.IsUserInRole(role);

}

Bật Cookie phía client

Cookie dùng để lưu thông tin qua các lần gọi phương thức, ví dụ trạng thái đăng nhập. Để bật Cookie, cần phải tạo ra một đối tượng CookieContainer và gán cho thuộc tính CookieContainer của service.

service.CookieContainer = new CookieContainer();

1. An toàn trước khả nǎng bị tấn công CSS (Cross-Site

Scripting)

Kiểu tấn công CSS điển hình nhất xảy ra khi tin tặc cố tình chèn một đoạn vǎn

bản có chứa script độc hại vào các form nhập dữ liệu. Nội dung nhập vào có thể

chứa các thẻ <OBJECT> hoặc <SCRIPT> cùng các đoạn mã hết sức nguy hiểm. Trình

duyệt, khi truy nhập site, cho rằng các srcipt này do máy chủ gửi tới, hoàn toàn

vô hại nên sẽ chạy nó ở cấp độ bảo mật bình thường, gây ra hậu quả tai hại cho

máy tính của người sử dụng .

Để bảo vệ khỏi bị tấn công theo kiểu CSS, cần chú ý ít nhất những điểm sau:

- Cập nhật thường xuyên các bản sửa lỗi bảo mật mới nhất của IIS và Windows.

- Lọc các ký tự đặc biệt do người sử dụng nhập vào như < > " ' % ( ) & + -

- Lọc để loại bỏ các ký tự đặc biệt, kết xuất trên cơ sở thông tin nhập vào của

người sử dụng. Xem kỹ các dữ liệu từ:

Code:

- Request.Form Collection

- Request.QueryString Conllection

- Request Object

- Database

- Cookie

- Các biến Session và Application

Để có thể lọc được, cần xác định cụ thể lược đồ mã hoá ký tự trên các trang Web,

trong thẻ META, ở phần header. Ví dụ:

<head> <META http-equiv="Content-Type" Content="text/html; charset=ISO-8859-1">

</head>

2. Ứng dụng có thể không cần sử dụng các cookie thường trực

Cookie thường trực là những tệp, được các ứng dụng Web gửi tới máy tính người sử

dụng và vẫn tồn tại trên ổ cứng của máy tính ngay cả khi họ không còn duyệt

site. Chúng lưu một số thông tin về người sử dụng để các ứng dụng Web tuỳ biến

nội dung cho phù hợp với từng đối tượng người sử dụng hoặc cho phép họ bỏ qua

giai đoạn đǎng ký đǎng nhập. Các cookie không thường trực được lưu trong bộ nhớ

máy tính của người sử dụng và chỉ tồn tại trong thời gian người sử dụng duyệt

site. IIS dựa vào các cookie không thường trực để xác định một phiên ASP. Không

có nó, IIS không thể duy trì bất kỳ các thông tin về phiên làm việc, chẳng hạn

như các biến phiên.

Nếu site của bạn sử dụng cookie thường trực, không nên yêu cầu IIS lưu trữ chúng

trong tệp log của IIS. Nếu tệp log lưu lại tất cả các thông tin đǎng nhập của

người sử dụng thì rất có nhiều khả nǎng, do một thoả hiệp nào đó, những thông

tin này có thể được tiết lộ ra ngoài.

3. Sử dụng SSL cho tất cả các trang nhạy cảm được chuyển trên mạng Internet

SSL mã hoá nội dung của các thông điệp TCP/IP để nó không bị nhòm ngó trên đường

truyền. SSL, hoặc một giải pháp mã hoá khác VPN chẳng hạn, rất cần thiết khi gửi

các thông tin nhạy cảm (như số thẻ tín dụng) qua mạng. Cơ hội thâm nhập đường

truyền và lấy cắp các thông tin bí mật là thấp song không phải không thể có.

Người sử dụng sẽ không đặt niềm tin vào site của bạn nếu các thông tin nhạy cảm

không được mã hoá.

Tuy nhiên, mặt trái của SSL là làm chậm lại hiệu nǎng thực hiện của ứng dụng.

Mức sử dụng tài nguyên hệ thống CPU đòi hỏi trong tiến trình mã hoá và giải mã

cho một trang SSL có thể cao hơn từ 10 đến 100% so với các trang không được bình

thường. Nếu máy chủ của bạn có lưu lượng các trang SSL cao, bạn có thể phải cân

nhắc tới việc sử dụng thêm một bộ tǎng tốc SSL phần cứng.

4. Yêu cầu người sử dụng đǎng nhập mỗi khi sử dụng ứng dụng

Nguyên tắc này áp dụng cho các ứng dụng có yêu cầu thủ tục đǎng nhập. Điều này

có nghĩa là việc đǎng nhập tự động dựa trên cookie là không được phép. Mặc dù

người sử dụng có thể thấy phiền hà nhưng nếu cho họ đǎng nhập tự động dựa trên

cookie sẽ có rất nhiều nguy hiểm (và như ta đã thấy ở phần trước, sử dụng các

cookie thường trực không phải lúc nào cũng phù hợp).

Một biện pháp tiếp theo cần thiết để bảo vệ mật khẩu là huỷ tính nǎng

Autocomplete của IE trên các trường mật khẩu. Điều này có thể thực hiện bằng

cách thêm thuộc tính AUTOCMPLET ="OFF" cho thẻ <FORM> hoặc <INPUT>. Ví dụ:

<input type="password" name="pwd" size=16 maxlength=16 AUTOCOMPLETE="OFF">

5. Log out người sử dụng ra khỏi hệ thống ngay khi họ rời site

Giả sử một người sử dụng đang xem một trang web trên site của bạn, sau đó họ

truy cập một site mới nhưng cuối cùng lại quyết định quay trở lại trang của bạn

bằng cách ấn phím BACK. Trong trường hợp này, ứng dụng phải yêu cầu người sử

dụng đǎng nhập lại một lần nữa. Phát hiện những tình huống tương tự như tình

huống vừa rồi của người sử dụng phải dựa hoàn toàn vào các script chạy ở phía

trình duyệt mà không thể dựa vào server vì nó không biết người sử dụng đã ở

những đâu. Cách giải quyết đầy đủ nhất cho vấn đề này là sử dụng một giải pháp

bảo mật Proxy Server như của Netegrity SiteMinder (CA Completes Netegrity Acquisition Advancing its Security Management Strategy).

Giải pháp Proxy Server sẽ giám sát mọi yêu cầu Web từ trình duyệt và ghi lại mọi

địa chỉ trình duyệt đã truy nhập để ứng dụng có thể kiểm tra.

Một cách thức không đầy đủ trong việc kiểm tra các giới hạn site có thể thực

hiện bằng cách thiết lập Request.ServerVariables("HTTP_REFERER"). Nếu người sử

dụng có gắng truy nhập bất kỳ trang nào khác với trang đǎng nhập, từ một URL của

một site khác, thì họ sẽ bị từ chối. Tuy nhiên, phương pháp này không thể ngǎn

ngừa một người sử dụng rời bỏ site của bạn để tới một site khác nhưng sau đó lại

quay trở lại site của bạn và tiếp tục phiên làm của họ.

6.Cắt kết nối khi người sử dụng không tương tác với site trong một khoảng thời

gian nhất định

Có hai giải pháp cho vấn đề này, một giải pháp ở phía máy chủ và một giải pháp

sử dụng script ở phía trình duyệt. Trong giải pháp thứ nhất, chúng ta sử dụng

IIS Manager và đặt giới hạn phiên ASP là một khoảng thời gian mong muốn nào đó

(giá trị mặc định là 20 phút). Trong ứng dụng, lưu trữ thông tin truy nhập vào

một biến phiên làm việc và kiểm tra nó trên mọi trang người sử dụng duyệt qua.

Nếu thông tin truy nhập không thuộc về một biến phiên, người sử dụng đã bị cắt

kết nối với site và ứng dụng cần định hướng họ sang trang truy nhập hệ thống.

Hơn nữa, mặc dù chưa phải có thể tin cậy tuyệt đối, bạn cũng có thể viết mã để

xử lý cắt kết nối người sử dụng trong sự kiện Session_OnEnd ở tệp Global.asa.

Giải pháp phía client sử dụng chút ít JavaScript. Chèn thêm đoạn mã sau vào đầu

của mọi trang Web kết xuất bởi ứng dụng:

Code:

<script Language="JavaScript">

window.setTimeout("window.navigate('Logout.asp')", 900000); </script>

'Logout.ASP' là trang để cắt kết nối người sử dụng với ứng dụng. 9000000 là

khoảng thời tối đa tính bằng mily giây người sử dụng vẫn duy trì phiên làm việc

của họ trong trường hợp không có tương tác nào với site.

7. Ứng dụng không cho phép login đồng thời

Yêu cầu này có nghĩa là tại một thời điểm, người sử dụng không thể truy nhập ứng

dụng với 2 phiên làm việc khác nhau. Đây cũng là nguyên tắc áp dụng cho phần lớn

các ứng dụng client/server và máy trạm khác.

Trong môi trường IIS/ASP, việc đáp ứng yêu cầu này không có gì khó khǎn. 2 sự

kiện Session_OnStart và Session_OnEnd trong Global.asa có thể sử dụng để kiểm

tra phiên truy nhập hiện thời của người sử dụng. Bạn cũng có thể áp dụng một

giải pháp của cơ sở dữ liệu để huỷ một phiên làm việc đang tồn tại khi một phiên

làm việc mới được bắt đầu.

8. Mã nguồn ứng dụng không chứa chú thích của người phát triển

Bất cứ cấp bảo mật nào cũng có thể thất bại. Trong những trường hợp khi đã truy

nhập được vào các tệp mã nguồn của Website thì những chú thích của người phát

triển sẽ là những trợ giúp đắc lực cho tin tặc, nguy hiểm nhất là trong trường

hợp mã nguồn có chứa những "viên ngọc" như tên và mật khẩu dùng trong quá trình

chạy thừ ứng dụng. Yêu cầu này chỉ áp dụng cho những tệp script, chằng hạn như

các trang ASP, không áp dụng cho các đoạn mã trong các đối tượng COM đã được

biên dịch.

Trước đây, những điểm yếu về bảo mật chưa được khắc phục của IIS làm cho các

script ASP trên một số site rất dễ bị đọc trộm. Nhiều tin tặc biết rằng học có

thể đọc các script này bằng cách thêm chuỗi "::$DATE" vào cuối yêu cầu truy xuất

trang. Để tránh các rủi ro có thể xảy ra, cần loại bỏ mọi chú thích trên trang

ASP, HTML hoặc mã JavaScript. Bạn có thể thực hiện bằng tay nhưng cách nhanh

nhất là viết một chương trình để loại bỏ các chú thích từ các loại tệp khác

nhau.

9. Không lưu trữ thông tin kết nối cơ sở dữ liệu trong global.asa

Thông tin kết nối cơ sở dữ liệu gồm tên server , tên cơ sở dữ liệu, thông tin

truy nhập SQL Server. Vì là một tệp vǎn bản, những thông tin trong global.asa có

thể bị lộ và rơi vào tay những đối tượng sử dụng không đúng mục đích. Những

thông tin này nên được lưu trữ ở những nơi khác. Hai cách phổ biến là lưu trữ nó

trong một tệp hoặc trong một Register.

Lưu trữ thông tin kết nối cơ sở dữ liệu trong một tệp và sau đó có thể đọc được

bằng File System Object hoặc XML Parser là cách an toàn hơn lưu trong

global.asa. Một giải pháp lưu thông tin trên tệp khác là sử dụng tệp UDL vì nó

cho phép lưu tất cả các chi tiết về kết nối. Chuỗi kết nối ADO sẽ trở thành

"FILE Name =C:\ Path_That_IUSR_<machinename>_Can_Get_To\MyDataLink .UDL" trong đó

tài khoản dịch vụ IIS, IUSR_<machinename>phải có quyền truy nhập để đọc được tệp

này.

Lưu các thông tin kết nối dưới hình thức được mã hoá trong registry là cách an

toàn nhất. Điều này yêu cầu ứng dụng phải viết các thông tin mã hoá vào trong

registry và các thành phần COM phải thu về và giải mã nó ở thời gian chạy.

Đối với IS 5, nếu sử dụng thành phần COM+, còn có một lựa chọn registry khác.

COM+ cho phép mỗi thành phần có Constructor được thiết lập trong Component

Services Manager. Vì không mã hoá thông tin, cách này cho phép người quản trị

site kiểm soát việc truy nhập cơ sở dữ liệu và thay đổi nó vào bất cứ lúc nào.

10. Các tệp audit log của cơ sở dữ liệu nên ghi nhận tất cả các thay đổi đối với

dữ liệu

Các tệp audit log của cơ sở dữ liệu cung cấp các thông tin quá khứ về những thay

đổi đối với dữ liệu trong các bảng. Một cách thông thường là tạo các trigger của

cơ sở dữ liệu để ghi lại tất cả các thao tác Insert, Update và Delete. Tuy

nhiên, ghi nhận tất cả thay đổi đối với mọi bản ghi có thể làm tǎng kích cỡ cơ

sở dữ liệu của bạn lên nhiều lần. Để giảm khối lượng dữ liệu lưu, cần phải cân

nhắc kỹ những thay đổi dữ liệu ở các bảng nào cần được ghi nhận. Mặc dù có thể

tạo các bảng và viết trigger bằng tay, nhưng để giảm nhẹ khối lượng công việc,

chúng ta có thể sử dụng giải pháp tự động. Một số sản phẩm và script miễn phí

tại địa chỉ http://www.sqldevpro.com/articles/MagicAuditingCode.htm có thể giúp

bạn thực hiện điều này.

11. Sử dụng các thủ tục lưu sẵn (stored procedure) để truy nhập cơ sở dữ liệu

Giới hạn việc truy nhập cơ sở dữ liệu, chỉ cho phép thực hiện thông qua các thủ

tục lưu sẵn có nhiều ưu điểm về bảo mật và hiệu nǎng thực hiện. Cách tiếp cận

này nên được tính đến ngay từ khi bắt đầu phát triển ứng dụng để việc triển khai

về sau được dễ dàng hơn.

Sử dụng thủ tục lưu sẵn an toàn hơn sử dụng ADO Recoredset hoặc các lệnh SQL bởi

vì qua nó cho phép chỉ có người sở hữu cơ sở dữ liệu, dbo, mới có quyền quyền

truy nhập tới bảng của tất cả những người sử dụng khác. Người sử dụng có quyền

thi hành trên các thủ tục lưu sẵn nhưng không có quyền đọc hoặc sửa đổi dữ liệu

trong các bảng một cách trực tiếp. Chỉ có dbo và người quản trị mới được phép sử

dụng Query Analyzer hoặc Crystal Reports để làm việc với dữ liệu. Vì vậy, yêu

cầu này có nghĩa là nếu Crystal Reports hoặc các công cụ tương tự khác được sử

dụng trên Website, việc thu nhận dữ liệu phải được triển khai qua các thủ tục

lưu sẵn.

Với cách tiếp cận này, chúng ta cần tạo 4 thủ tục cho mỗi bảng cho các lệnh

Select, Insert, Update and Delete. Bạn cũng có thể tạo một lớp bao (wrapper

class) đóng vai trò là giao diện của thủ tục trong tầng truy nhập cơ sở dữ liệu

của ứng dụng.

Dưới đây là thí dụ về thủ tục chèn dữ liệu vào bảng Authors trong cơ sở dữ liệu

của một nhà xuất bản:

Code:

CREATE PROCEDURE dp_authors_ins @au_id varchar(11), @au_lname varchar(40),

@au_fname varchar(20), @phone char(12) = NULL OUTPUT , @address varchar(40) =

NULL , @city varchar(20) = NULL , @state char(2) = NULL , @zip char(5) = NULL ,

@contract bit AS IF @phone IS Null SET @phone = ('UNKNOWN')

INSERT INTO authors WITH (ROWLOCK) ( au_id, au_lname, au_fname, phone, address,

city, state, zip, contract) VALUES (@au_id, @au_lname, @au_fname, @phone,

@address, @city, @state, @zip, @contract)

SELECT @phone = phone FROM authors WHERE au_id = @au_id

GO

Đọc và thay đổi dữ liệu có hơi khác với cách tiếp cận thủ tục lưu sẵn. Thay vì

làm việc với các recorset ADO hoặc tạo các câu lệnh SQL để thi hành trên server,

tất cả việc truy nhập cơ sở dữ liệu đều thông qua đối tượng điều khiển ADO. Các

đối tượng điều khiển ADO sẽ thi hành thủ tục lưu sẵn này.

Bảo mật website bằng cách sử dụng robots.txt 21-06-2012 - 15:27

Ứng dụng tệp tin loại trừ robots.txt trong trường hợp đặc biệt với Googlebot.

Bài viết này chúng ta sẽ tìm hiểu cụ thể các thức áp dụng tệp tin robots.txt này cho máy tìm kiếm Google mà cụ thể là các User Agent của Google.

Đây là bài viết thứ ba trong một loạt series bốn bài viết về Robots Exclusion Protocol (REP) :

Robots.txt disallows Web Robot, User-agent

Bài viết giới thiệu về Robots Exclusion Protocol với tệp tin robots.txt và cú pháp, cách sử dụng đúng và danh sách các User Agent Names.

Robots, HTML Meta và Google, Yahoo, Microsoft

Giới thiệu về Robots Exclusion Protocol (REP), qui ước chung của Google, Yahoo và Microsoft : Qui ước robots.txt và qui ước HTML META Tags.

Googlebot và Robots.txt : Allow, Disallow

Cách ứng dụng Robots Exclusion Protocol (REP) bằng việc sử dụng tệp tin robots.txt đối với máy tìm kiếm Google. Cách biên dịch đặc biệt tệp tin robots.txt của spider GoogleBot.

Robots META Tag – Metadata Elements

Ứng dụng Robots Exclusion Protocol (REP) thông qua sử dụng thẻ Metadata Robots cho các trang đơn lẻ.

Các User Agent của Google

Google có vài user-agent chính. Bạn có thể ngăn chúng bằng cách thêm tên của bọ tìm kiếm tương ứng và trong dòng User-agent tương ứng trong bảng ghi robots.txt. Nếu bạn chặn Googlebot thì có nghĩa là bạn chặn tất cả các bọ tìm kiếm với từ khóa “Googlebot”.

Googlebot

Đánh chỉ số từ các chỉ mục cũ và mới của Google.

Googlebot-Mobile

Đánh chỉ số cho các thiết bị cầm tay hoặc di động.

Googlebot-Image

Đánh chỉ số các tệp tin ảnh.

Mediapartners-Google

Xuất hiện trong các trang dăng quảng cáo của Google Adsense.

Adsbot-Google

Đánh chỉ số các trang được nhà quảng cáo sử dụng giới thiệu sản phẩm hay dịch vụ thông qua Google Adwords. Nó cho phép đánh giá chất lượng của trang dùng dịch vụ Adwords.

Chặn Googlebot

Để chặn toàn bộ Googlebot thì bạn thêm cú pháp sau vào file robots loại trừ :

User-agent: Googlebot

Disallow: /

Cho phép Googlebot

Trong trường hợp bạn muốn chặn tất cả các bọ tìm kiếm khác trừ một robot, Googlebot chẳng hạn, thì bạn có thể sử dụng cú pháp sau. Tuy nhiên nếu bạn không muốn trang liên quan biến mất khỏi kết quả tìm kiếm của các máy tìm kiếm như Yahoo, MSN Live hay Ask thì bạn không nên làm như thế.

User-agent: *

Disallow: /

User-agent: Googlebot

Disallow:

Cho phép mở rộng

Google hỗ trợ cú pháp mở rộng “Allow” trong tệp tin robots.txt. Có nhiều máy tìm kiếm không hỗ trợ phần mở rộng này, vì thế bạn nên tham khảo kỹ. Dòng lệnh “Allow” hoạt động cũng giống như “Disallow” chỉ khác là nó liệt kê các thư mục hay trang bạn cho phép đánh chỉ số.

Bạn có thể sử dụng đồng thời “Allow” và “Disallow” cùng nhau. Chẳng hạn để cấm tất cả các trang trong một thư mục “seoblog” chẳng hạn, trừ tệp tin “quang-ba-web.html”, bạn hãy làm như sau :

User-agent: Googlebot

Disallow: /seoblog/

Allow: /seoblog/quang-ba-web.html

Còn trong trường hợp bạn muốn chặn Googlebot và sau đó lại vẫn muốn cho các bot khác của Google (Googlebot-Mobile) chẳng hạn, bạn có thể sử dụng lệnh Allow như sau :

User-agent: Googlebot

Disallow: /

User-agent: Googlebot-Mobile

Allow: /

Sử dụng mẫu tổ hợp

Đặc biệt hữu ích trong trường hợp bạn không muốn phải liệt kê tất cả các trang mà bạn muốn chặn. Đây là phần đuôi mở rộng mà GoogleBot hỗ trợ. Chú ý là các máy tìm kiếm khác chưa chắc đã hỗ trợ tính năng này.

Mẫu tổ hợp chuỗi các ký tự sử dụng dấu sao (*)

Bạn có thể sử dụng dấu sao (*) để liệt kê tổ hợp chuỗi các lkys tự. Ví dụ bạn có thể chặn một loạt các thư mục con bắt đầu bằng chữ wp (ví dụ wp-admin, wp-content cho blog WordPress) như sau :

User-agent: Googlebot

Disallow: /wp*/

Để chặn tất cả đường dẫn URL mà chứa ký tự (?) chứa tham biến (trong ngôn ngữ PHP), bạn hãy làm như sau :

User-agent: *

Disallow: /*?

Kiểm tra phần kết của chuỗi ký tự URL bằng $

Bạn cũng có thể sử dụng dấu dollard ($) để liệt kê các URL có phần kết tương ứng. Ví dụ để chặn tất cả các đường dẫn URL kết thúc với pdf (phiên bản pdf trên website để tránh trùng nội dung chẳng hạn) :

User-agent: Googlebot

Disallow: /*.pdf$

Bạn cũng có thể sử dụng tổ hợp kết này với lệnh Allow. Ví dụ nếu như có dấu hỏi ? tương ứng với một session ID, bạn có thể loại trừ chúng để tránh cho GoogleBot phải đánh chỉ số một nội dung trùng lặp. Thế nhưng các URLs kết thúc bởi dấu hỏi ? lại là một phiên bản trang mà bạn muốn thêm vào. Trong trường hợp này, hãy đặt tệp tin robots.txt của bạn như sau :

User-agent: *

Allow: /*?$

Disallow: /*?

Dòng lệnh Disallow:/ *? sẽ chặn tất cả các URL có chứa ký tự ? (Cụ thể là nó sẽ chặn tất cả các URL bắt đầu bằng tên miền, tiếp theo các ký tự, tiếp theo là dấu hỏi ?, tiếp theo bởi bất kể ký tự nào khác)

Dòng lệnh Allow: /*?$ sẽ cho phép bất kể đường dẫn nào kết thúc bởi dấu hỏi ? (Cụ thể là với bất kể URL nào bắt đầu bằng tên miên, theo bởi chuỗi ký tự, theo tiêp bởi dấu hỏi ?, không có ký tự nào nằm sau dấu hỏi này).