As we discussed when we went over Web security issues, the vast majority of Web sites and applications in use today make use of databases in order to store the information they display and process. In some cases, such applications may hold very sensitive data, such as tax returns, medical data, or legal records; or they may contain only the contents of a discussion forum on knitting. In either case, the data such applications hold is important to the owners of the application and they would be inconvenienced, at the very least, if it were damaged or manipulated in an unauthorized manner. Show
A number of issues can cause trouble in ensuring the security of our databases. The canonical list includes the following [8]: ■Unauthenticated flaws in network protocols ■Authenticated flaws in network protocols ■Flaws in authentication protocols ■Unauthenticated access to functionality ■Arbitrary code execution in intrinsic SQL elements ■Arbitrary code execution in securable SQL elements ■Privilege escalation via SQL injection ■Local privilege escalation issues Although this may seem like a horribly complex set of issues for us to worry about, we can break them down into four major categories, as shown in Figure 10.2.  Figure 10.2. Categories of Database Security Issues Protocol IssuesWe might find a number of issues in the protocols in use by any given database. We can look at the network protocols used to communicate with the database, some of which will need a set of credentials in order to use and some of which will not. In either case, there is often a steady stream of vulnerabilities for most any major database product and version we might care to examine. Such vulnerabilities often involve some of the more common software development issues, such as the buffer overflows we discussed at the beginning of this chapter. When we are dealing with known protocol issues, the absolute best defense is to ensure that we are using the most current software version and patches for the database software in question, as we discussed in Chapter 9. Defending against presently unknown network protocol issues often revolves around limiting access to our databases, either in the sense of actually limiting access to who is able to connect to the database over the network, using some of the methods we discussed in Chapter 8, or, in the case of authenticated protocol problems, by limiting the privileges and accounts we make available for the database itself, following the principle of least privilege. We may also have issues in the authentication protocols used by our database, depending on the specific software and version we have in use. In general, the older and more out-of-date our software becomes, the more likely it is that we are using an authentication protocol that is not robust. Many older applications will use authentication protocols we know to have been broken at some point, or to have obvious architectural flaws, such as sending login credentials over the network in plaintext (refer to Chapter 5), as Telnet does. Again, the best defense here is to ensure that we are on current versions of the software we are using. Unauthenticated AccessWhen we give a user or process the opportunity to interact with our database without supplying a set of credentials, we create the possibility for security issues. Such issues may be related to simple queries to the database through a Web interface, in which we might accidentally expose information contained in the database; or we might expose information on the database itself, such as a version number, giving an attacker additional material with which to compromise our application. We might also experience a wide variety of issues related to the secure software development practices we discussed at the beginning of the chapter. If the user or process is forced to send us a set of credentials to begin a transaction, we can monitor, or place limits on, what the user or process is allowed to do, based on those credentials. If we allow access to part of our application or tool set without requiring these credentials, we may lose visibility and control over what actions are taking place. Arbitrary Code ExecutionWe can find a number of areas for security flaws in the languages we use to talk to databases. Generally, these are concentrated on SQL, as it is the most common database language in use. In the default SQL language, a number of built-in elements are possible security risks, some of which we can control access to and some of which we cannot. In these language elements, we may find a number of issues related to bugs in the software we are using, or issues spawned by not using secure coding practices, that might allow us to execute arbitrary code within the application. For example, a flaw allowing us to conduct a buffer overflow, as we discussed earlier in this chapter, might enable us to insert attack code into the memory space used by the database or the operating system, and compromise either or both of them. Our best defenses against such attacks are twofold. From the consumer side, we should stay current on the version and patch levels for our software. From the vendor side, we should mandate secure coding practices, in all cases, in order to eliminate the vulnerabilities in the first place, as well as conducting internal reviews to ensure that such practices are actually being followed. Privilege EscalationOur last category of major database security issues is that of privilege escalation. In essence, privilege escalation is a category of attack in which we make use of any of a number of methods to increase the level of access above what we are authorized to have, or have managed to gain on the system or application through attack. Generally speaking, privilege escalation is aimed at gaining administrative access to the software in order to carry out other attacks without needing to worry about not having the access required. As we mentioned earlier in the chapter, SQL injection is a very common attack against databases that are accessible through a Web interface and is largely an issue of not filtering or validating inputs properly. SQL injection can be used to gain information from the database in an unauthorized manner, modify data contained in the database, and perform many other similar activities. SQL injection can also be used to gain or escalate privileges in the database. One of the more common SQL injection examples is to send the string ' or '1'='1 as the input in a username field for an application. If the application has not filtered the input properly, this may cause it to automatically record that we have entered a legitimate username, which we have clearly not done, allowing us to potentially escalate the level of privilege to which we have access. Additional ResourcesFor those interested in more information regarding SQL injection and database security in general, two books available from Syngress are Securing SQL Server by Denny Cherry (ISBN: 9781597496254) and SQL Injection Attacks and Defense by Justin Clarke (ISBN: 9781597494243). Both are great resources from very knowledgeable folks. An additional area of concern for privilege escalation is from an operating system perspective. Database applications are processes running on the operating system, using the credentials and privileges of an operating system user, just like a Web browser or any other application we might want to run. If we are not careful to protect our operating systems and the user accounts that run on them, as we talked about in Chapters 8 and 9Chapter 8Chapter 9, any database security measures we might put in place may be for naught. If an attacker gains access to the account under which the database software is running, he or she will likely have privileges to do anything he or she might care to do, including deleting the database itself, changing passwords for any of the database users, changing the settings for the way the database functions, manipulating data, and so on. Our best defenses against operating system issues such as these are the set of hardening and mitigation steps we discussed in Chapter 9. If we can keep attackers from compromising our system in the first place, we can largely avoid this particular concern. View chapterPurchase book Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597496537000104 Application SecurityJason Andress, in The Basics of Information Security (Second Edition), 2014 Database securityAs we discussed when we went over Web security issues, the vast majority of Web sites and applications in use today make use of databases in order to store the information they display and process. In some cases, such applications may hold very sensitive data, such as tax returns, medical data, or legal records; or they may contain only the contents of a discussion forum on knitting. In either case, the data such applications hold is important to the owners of the application and they would be inconvenienced, at the very least, if it were damaged or manipulated in an unauthorized manner. A number of issues can cause trouble in ensuring the security of our databases. The canonical list includes the following [8]: •Unauthenticated flaws in network protocols •Authenticated flaws in network protocols •Flaws in authentication protocols •Unauthenticated access to functionality •Arbitrary code execution in intrinsic SQL elements •Arbitrary code execution in securable SQL elements •Privilege escalation via SQL injection •Local privilege escalation issues Although this may seem like a horribly complex set of issues for us to worry about, we can break them down into four major categories, as shown in Figure 12.2. Figure 12.2. Categories of database security issues. Protocol issuesWe might find a number of issues in the protocols in use by any given database. We can look at the network protocols used to communicate with the database, some of which will need a set of credentials in order to use and some of which will not. In either case, there is often a steady stream of vulnerabilities for most any major database product and version we might care to examine. Such vulnerabilities often involve some of the more common software development issues, such as the buffer overflows we discussed at the beginning of this chapter. When we are dealing with known protocol issues, the absolute best defense is to ensure that we are using the most current software version and patches for the database software in question, as we discussed in Chapter 11. Defending against presently unknown network protocol issues often revolves around limiting access to our databases, either in the sense of actually limiting access to who is able to connect to the database over the network, using some of the methods we discussed in Chapter 10, or, in the case of authenticated protocol problems, by limiting the privileges and accounts we make available for the database itself, following the principle of least privilege. We may also have issues in the authentication protocols used by our database, depending on the specific software and version we have in use. In general, the older and more out-of-date our software becomes, the more likely it is that we are using an authentication protocol that is not robust. Many older applications will use authentication protocols we know to have been broken at some point, or to have obvious architectural flaws, such as sending login credentials over the network in plaintext (refer to Chapter 5), as Telnet does. Again, the best defense here is to ensure that we are on current versions of the software we are using. Unauthenticated accessWhen we give a user or process the opportunity to interact with our database without supplying a set of credentials, we create the possibility for security issues. Such issues may be related to simple queries to the database through a Web interface, in which we might accidentally expose information contained in the database; or we might expose information on the database itself, such as a version number, giving an attacker additional material with which to compromise our application. We might also experience a wide variety of issues related to the secure software development practices we discussed at the beginning of the chapter. If the user or process is forced to send us a set of credentials to begin a transaction, we can monitor, or place limits on, what the user or process is allowed to do, based on those credentials. If we allow access to part of our application or tool set without requiring these credentials, we may lose visibility and control over what actions are taking place. Arbitrary code executionWe can find a number of areas for security flaws in the languages we use to talk to databases. Generally, these are concentrated on SQL, as it is the most common database language in use. In the default SQL language, a number of built-in elements are possible security risks, some of which we can control access to and some of which we cannot. In these language elements, we may find a number of issues related to bugs in the software we are using, or issues spawned by not using secure coding practices, that might allow us to execute arbitrary code within the application. For example, a flaw allowing us to conduct a buffer overflow, as we discussed earlier in this chapter, might enable us to insert attack code into the memory space used by the database or the operating system, and compromise either or both of them. Our best defenses against such attacks are twofold. From the consumer side, we should stay current on the version and patch levels for our software. From the vendor side, we should mandate secure coding practices, in all cases, in order to eliminate the vulnerabilities in the first place, as well as conducting internal reviews to ensure that such practices are actually being followed. Privilege escalationOur last category of major database security issues is that of privilege escalation. In essence, privilege escalation is a category of attack in which we make use of any of a number of methods to increase the level of access above what we are authorized to have or have managed to gain on the system or application through attack. Generally speaking, privilege escalation is aimed at gaining administrative access to the software in order to carry out other attacks without needing to worry about not having the access required. As we mentioned earlier in the chapter, SQL injection is a very common attack against databases that are accessible through a Web interface and is largely an issue of not filtering or validating inputs properly. SQL injection can be used to gain information from the database in an unauthorized manner, modify data contained in the database, and perform many other similar activities. SQL injection can also be used to gain or escalate privileges in the database. One of the more common SQL injection examples is to send the string “or” 1′=1′ as the input in a username field for an application. If the application has not filtered the input properly, this may cause it to automatically record that we have entered a legitimate username, which we have clearly not done, allowing us to potentially escalate the level of privilege to which we have access. View chapterPurchase book Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780128007440000129 Configuring Network AccessTony Piltzecker, Brien Posey, in The Best Damn Windows Server 2008 Book Period (Second Edition), 2008 Remote Access PolicyRemote access policies are an ordered set of rules that define how connections are either authorized or rejected. For each rule, there are one or more conditions, a set of profile settings, and a remote access permission setting. If a connection is authorized, the remote access policy profile specifies a set of connection restrictions. The dial-in properties of the user account also provide a set of restrictions. Where applicable, user account connection restrictions override the remote access policy profile connection restrictions. For servers running the RRAS that are configured for the Windows authentication provider, remote access policies are administered from RRAS and apply only to the connections of the RRAS server. Centralized management of remote access policies is also used when you have remote access servers that are running RRAS. Remote access policies validate a number of connection settings before authorizing the connection, including the following: ▪Remote access permission ▪Group membership ▪Type of connection ▪Time of day ▪Authentication methods ▪Advanced conditions such as access server identity, access client phone number, or Media Access Control (MAC) address ▪Whether user account dial-in properties are ignored ▪Whether unauthenticated access is allowed After the connection is authorized, remote access policies can also be used to specify connection restrictions, including the following: ▪Idle timeout time ▪Maximum session time ▪Encryption strength ▪IP packet filters Advanced restrictions: ▪IP address for PPP connections ▪Static routes Additionally, you can vary connection restrictions based on the following settings: ▪Group membership ▪Type of connection ▪Time of day ▪Authentication methods ▪Identity of the access server ▪Access client phone number or MAC address ▪Whether unauthenticated access is allowed For example, you can have policies that specify different maximum session times for different types of connections or groups. Additionally, you can also specify restricted access for business partners or unauthenticated connections. All of this can be configured using the RRAS panel on the client computer, as shown in Figure 6.5. This is accessible as follows: Figure 6.5. Network Policy and Access Tab 1Open Server Manager and expand the Roles tab. 2Expand the Network Policy and Access Service tab, as seen in Figure 6.5 3Expand the Routing and Remote Access panel and right click for Properties This will allow you to set up configurations for your remote access policies. View chapterPurchase book Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597492737000069 MCSA/MCSE 70-291: Configuring the Windows 2003 Routing and Remote Access Service LAN Routing, Dial-up Services, and Routing ProtocolsDeborah Littlejohn Shinder, ... Laura Hunter, in MCSA/MCSE (Exam 70-291) Study Guide, 2003 Configuring Remote Access PoliciesA traditional LAN is usually located within the physical confines of a building. The systems within the bounds of the LAN are administered by an individual or group of individuals and usually a policy is in place to guide the administration and configuration. When users connect from outside the confines of the LAN, often the system the client connects from is not administered by the corporate administrator or administrators. This can present configuration problems as well as security problems. Remote access policies help administrators apply a consistent policy to non-LAN machines, the machines that are often not directly administered within the confines of the corporate LAN. Through the use of remote access policies, administrators can limit the access rights and privileges of remote users and computers by validating connections and can specify connection restrictions. Connection settings that can be validated by standard remote access policy settings include the following: ■Authentication methods ■Group membership ■Remote access permission ■Time of day ■Type of connection Advanced remote access policy validation settings include the following: ■Access server identity ■Access client phone number or MAC address ■Whether user account dial-in properties are ignored ■Whether unauthenticated access is allowed Authentication methods include the following: ■PEAP ■EAP ■MS-CHAP ■MS-CHAP version 2 ■CHAP ■PAP ■Unauthenticated access
|
