70-340 Implementing Security for Applications with Microsoft Visual C# .NET Practice Exam

Demo Question 1.

You are an application developer for EliteCertify.com. You are testing an application that was developed by another developer. The application maintains its own list of authorized users. Each user is assigned a security level of 1, 2, or 3. When a new user account is created, the security level for that user is entered into a text box. The new user account information is saved in a Microsoft SQL Server table by using a stored procedure. You verify that user accounts that have any of the three security levels can perform only the intended actions within the application. You need to identify any security vulnerabilities in the portion of the application that creates new user accounts. What should you do?

A. Use SQL Query Analyzer to create a new user account that has a security level of 2. Test the application to see if the new user account can log on to the application.
B. Create a new user account that has a security level other than 1, 2, or 3. Test the application to see what the new user account can do.
C. Use Osql.exe to call the stored procedure and create a new user account that has a security level of 3. Test the application to see what the new user account can do.
D. Create a new user account that has a security level of 3. Test the application to see what the new user account can do.


Display Answer

Answer: B

Explanation: Security testing is about validating your application's security services and identifying potential security flaws. This section contains important testing recommendations for verifying that you have created a securable application. Since attackers have no standard method of breaking into things, there are no standard methods of conducting security testing. Also, there are few tools available at this time to test security aspects thoroughly. Since a functional bug in an application can also represent a potential security flaw, you need to conduct functional testing prior to conducting security testing. It is important to note that security testing will not prove conclusively that an application is secure. Instead, it serves only to validate the effectiveness of instituted countermeasures, which were chosen based upon presumptions that were made during the threat analysis phase. Provided below are some suggestions for testing the securability of your application. There are some security issues you should be aware of when you test your smart documents. These security measures, described in the Security section, are in place to provide security for Microsoft(r) Office 2003 users. However, during testing, you may want to disable the XML expansion pack security check, if possible, or you may want to create a test environment that meets the security requirements of your users. The following topics provide additional information about security within a development and testing environment: Disabling the XML Expansion Pack Security Check Digital Code Signing for Testing Purposes Creating a Digital Certificate for Testing Purposes Delay Signing a Smart Document Assembly Testing a Signed XML Expansion Pack Test for Buffer Overflows One of the first security bugs exploited in computer history was a buffer overflow. Buffer overflows continue to be one of the most dangerous and most commonly occurring weaknesses. Attempts to exploit this type of vulnerability can result in problems ranging from crashing the application to an attacker inserting and executing malignant code in the application process. When writing data to buffers, it is imperative that developers not write more to the buffer than it can possibly hold. If the amount of data being written exceeds the buffer space that has been allocated, a buffer overflow occurs. When a buffer overflow occurs, data is written into parts of memory that may be allocated for other purposes. A worst-case scenario is when the buffer overflow contains malicious code that is then executed. Buffer overflows account for a large percentage of security vulnerabilities. Conduct source code security reviews Depending upon the sensitivity of the application in question, it might be prudent to conduct a security audit of the application source code. A source code audit should not be confused with a code review. The purpose of a standard code review is to identify general code defects that affect the functionality of the code. The purpose of a source code security review is to identify security flaws, intentional or otherwise. Such a review would be especially warranted when developing applications that handle financial transactions or provide for public safety. Validate contingency plansThere will always be a potential that an application's security defenses can be breached and it is only prudent that contingency plans are in place and validated. What steps will be taken if a virus is detected on your application server or in your data center? When security is thwarted, reactions must occur rapidly to prevent further damage. Find out if your contingency plans will work before they must be battle-tested. Attack your applicationTesters are accustomed to tormenting applications in an attempt to make them fail. Hacking your own application is a similar, but more focused, process. When attempting to attack your application, you should be looking for exploitable flaws that represent a weak spot in your application's defenses.