Cookies offer an excellent way to keep small bits of information about the user readily available so that they don't have to be looked up again. They can allow you to keep users' numeric IDs handy instead of their logon names, which makes getting back to their security and authorization easier and quicker. However, cookies represent a dangerous risk: Users may choose to tamper with the information and see what havoc it might cause. Risks of cookie tampering To understand how using cookies can create huge security risks, consider a site that stores the user's ID in a database in a cookie. The cookie is persistent, and the site never validates the information in the cookie. It's assumed to be correct. The user goes to the site and logs in. He or she looks at the cookie file and determines that only an ID is being stored in it. The user resets the number in the file to 1 and logs back into the site. For most sites, the super user is the first ID inserted into the database, and it's usually never disabled. If the site doesn't validate the value from the cookie, the user has become a complete administrator with a trivial amount of text editing. Any unchecked information placed in a cookie can represent a potential security problem. Question: 25 You are an application developer for Company.com. To prevent malicious code from running, a written company policy does not permit developers to log on by using accounts that have more permissions than necessary. Your user account is a member of the Users group and the VS Developers group. You attempt to run an application that requires Administrator-level permissions. You receive an error message that states that permission is denied. You need to be able to run the application. What should you do? A. Ask the network administrator to add your user account to the domain Administrators group. B. Ask the administrator of your client computer to add your user account to the local Administrators group. C. Add the administrator of your client computer to add your user account to the Power Users group. D. Run the application by using the runas command and specify a user account in the local Administrators group. Answer: D
Exam Name: Implementing Security for Applications with Microsoft Visual Basic .NET Exam Type: Microsoft Exam Code: 70-330 Total Questions: 85 Page 33 of 129 Explanation Run Using a Least-Privileged Account You should develop applications using a non administrator account. Doing so is important primarily to limit the exposure of the logged on user and to help you to design more secure software. For example, if you design, develop, and exams an application while you are interactively logged in as an administrator, you are much more likely to end up with software that requires administrative privileges to run. You should not generally log on using the local administrator account. The account that you use on a daily basis should not be a member of the local Administrators group. Sometimes you might still need an account that has administrative privileges—for example, when you install software or edit the registry. Because the default local
You've reached the end of your free preview.
Want to read all 129 pages?
- Spring '16
- Microsoft Corporation, hash function, .NET Framework, Microsoft Visual Studio, Cryptographic hash function