|
ie doesn''''t exist, ASP.Net redirects the request to the login page. If the login is successful, the authentication cookie is created and passed to the user’s browser. This can be configured to be a permanent cookie or a session-based cookie. Possibly slightly more secure is a session-based cookie where the cookie is destroyed when the user leaves the application or the session times out. This prevents someone else accessing the application from the user’s client machine without having to login.
Given the above scenario we have two security issues for further consideration:
- How secure is the cookie based access? Note above that encryption and validation are used by default. How secure are these in reality?
Validation works exactly the same for authentication cookies as it does for view state: the <machineKey> element''''s validationKey is appended to the cookie, the resulting value is hashed, and the hash is appended to the cookie. When the cookie is returned in a request, ASP.Net verifies that it wasn''''t tampered with by rehashing the cookie and comparing the new hash to the one accompanying the cookie. Encryption works by encrypting the cookie, hash value and all with <machineKey>''''s decryptionKey attribute. Validation consumes less CPU time than encryption and prevents tampering. It does not, however, prevent someone from intercepting an authentication cookie and reading its contents.
Encrypted cookies can''''t be read or altered, but they can be stolen and used illicitly. Time-outs are the only protection a cookie offers against replay attacks, and they apply to session cookies only. The most reliable way to prevent someone from spoofing your site with a stolen authentication cookie is to use an encrypted communications link (HTTPS). Talking of which, this is one situation when you might want to turn off both encryption and validation. There is little point encrypting the communication again if you are already using HTTPS.
Whilst on the subject of cookies, remember also that cookie support can be turned off via the client browser. This should also be borne in mind when designing your application.
- How secure is the logging on procedure to a web form? Does it use clear text username and password transmission that could be susceptible to observation, capture and subsequent misuse?
Yes is the answer. Thus if you want a secure solution but don''''t want the overhead of encrypting communications to all parts of your site, consider at least submitting user names and passwords over HTTPS, this assuming your web hosting service provides this.
To reiterate, the forms security model allows us to configure keys to use for encryption and decryption of forms authentication cookie data. Here we have a problem - this only encrypts the cookie data - the initial login screen data, i.e. email / password is not encrypted. We are using standard HTTP transmitting data in clear text which is susceptible to interception. The only way around this is to go to HTTPS and a secure communication channel.
Which perhaps begs the question – what is the point of encrypting the cookie data if our access is susceptible anyway if we are using an unsecured communication channel? Well, if we enable cookie authentication when we first login then subsequent interaction with the server will be more secure. After that initial login a malicious attacker could not easily gain our login details and gain access to the site simply by examining the contents of the packets of information passed to and from the web server. However, note the earlier comments on cookie theft. It is important to understand these concepts and the impact our decisions have on the overall security of our application data.
It is perhaps unsurprising given the above that for the most secure applications:
- A secure HTTPS channel is used whenever dealing with username/ password/ related data.
- Cookies are not exclusively relied upon: often though recall of certain information is cookie based important transactions still require authorization via an encrypted password or number.
It is up to the application architect/ programmer to decide whether this level of security is appropriate to their system.
Finally, before we actually come up with some code remember that forms based security secures only ASP.Net resources. It doesn’t protect HTML files, for example. Just because you have secured a directory using web.config / ASP.Net doesn’t mean you have secured all files in that directory. To do this you could look at features available via IIS.
The ''''Application''''Finally to the code and making our ASP.Net application as secure as possible using the facilities ASP.Net provides. Taking the above described scenario where we have a secure sub-directory the files within which we wish to protect. However, we anticipate there will only be a handful of users who will need access to the directory and hence this is a suitable problem domain to be addressed with a web.config based authority solution as earlier decided.
Starting with our web.config file. We can secure the sub-directory either via the location element, as described above, but just to demonstrate the alternative double web.config based approach, here is the web.config at the root level:
<configuration>
<system.web>
<authentication mode="Forms">
<forms name=".AUTHCOOKIE" loginUrl="login_credentials.aspx" protection="All">
<credentials passwordFormat="Clear">
<user name="chris" password="password" />
</credentials>
</forms>
</authentication>
<machineKey validationKey="AutoGenerate" decryptionKey="AutoGenerate" validation="SHA1" />
<authorization>
<allow users="*" />
</authorization>
</system.web>
</configuration> You can see that this sets up forms based security enabling validation and encryption and specifies a credentials list of one user, currently in Cleartext format but shortly we''''ll see how to encrypt the password via SHA1. You''''ll also see that this file doesn’t actually restrict user access at all so URL based authentication will not be used at the root level of our application. However, if we extend the configuration for the secure sub-directory via an additional web.config file:
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration> Then if a user attempts to access an ASP.Net resource in secure they will be dealt with according to the combination of directives in the web.config file and inherited from the parent web.config file, and machine.config file for that matter.
Onto the login file: you will need form fields to allow entry of username and password data. Note that security will be further improved by enforcing minimum standards on passwords (e.g. length), which can be achieved by validation controls. There is only minimal validation in the example. Note that there is no facility to request a ‘persistent cookie’ as this provides a minor security risk. It is up to you to decide whether a permanent cookie is acceptable in your application domain.
Then in the login file, login_credentials.aspx, after allowing the user to enter username and password data, in the sub executed on the server when the submit form button is clicked we validate the entered data against the web.config credentials data, achieved simply as follows:
If FormsAuthentication.Authenticate(Username.Value, UserPass.Value) Then
FormsAuthentication.RedirectFromLoginPage (UserName.Value, false)
Else
Msg.text="credentials not valid"
End If Could it be any simpler? The FormsAuthentication object knows what authority it needs to validate against as this has been specified in the web.config file. If the user details match, the code proceeds to redirect back to the secured resource and also sets the cookie for the user session based on the user name entered. The parameter ''''false'''' indicates that the cookie should not be permanently stored on the client machine. Its lifetime will be the duration of the user session by default. This can be altered if so desired.
Back to web.config to improve the security. The details are being stored unencrypted – we can encrypt them with the aforementioned HashPasswordForStoringInConfigFile of the FormsAuthentication class, achieved simply as follows:
Private Function encode(ByVal cleartext As String) As String
encode = FormsAuthentication.HashPasswordForStoringInConfigFile(cleartext, "SHA1")
Return encode
End Function This is the key function of the encode.aspx file provided with the code download, which accepts a text string (the original password – ‘password’ in this case) and outputs a SHA1 encoded version care of the above function.
Thus, our new improved configuration section of our root web.config file becomes:
<credentials passwordFormat="SHA1">
<user name="chris" password="5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8" />
</credentials> To summarize the involved files:
Root/web.config
root web 上一页 [1] [2] [3] [4] 下一页
[网络安全]赶尽杀绝—查杀AOL Trojan木马 [Sql Server]不用SqlTransaction执行数据库事务处理
[Web开发]用SqlCommandBuilder 实现批量更新 [Web开发]NET下随机数(Random)的产生（应用）
[Web开发]出现SqlTransaction 已完成;它再也无法使用的错误… [Web开发]出现SqlTransaction 已完成;它再也无法使用的错误…
[平面设计]Flash随机random函数详解 [平面设计]网页动画制作大师 Animation Shop
[平面设计]制作动态GIF图像的好帮手─Coffee GIf Animator [平面设计]可以有效降低网页动画大小的网页动画制作软件—An…
|
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
