* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Proceedings Template - WORD - Animated DataBase Courseware
Oracle Database wikipedia , lookup
Microsoft Access wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Concurrency control wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Ingres (database) wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Functional Database Model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
ContactPoint wikipedia , lookup
Clusterpoint wikipedia , lookup
2.2. Integrity and Security Matrices A frequent requirement in database classes is for students to implement a prototype database application where several design documents are required. One such document is a matrix, such as the one shown in Figure 2 which displays the possible operations that an input form performs on a table. This type of matrix serves two purposes. First, it provides an overview of the system as well as identifies implementation difficulties. The example, Figure 2 clearly shows that the ORDER form is by far the most difficult because it accesses five different tables, while the other forms only access one table. A second advantage is that the matrix visually depicts rules of integrity. For instance, if any change such as change in a datatype, were made in any of the tables, all forms affected by this change can easily be identified by parsing the table’s column in the matrix. Although this type of matrix appears simple, students have tremendous difficulty creating it. The matrix animation allows a user to select an operation inside the matrix and then a simulation of the form/program performing the operation on the table will be displayed. For example, if a user clicks on ‘U’ of the customers form on the customers table, a simulation of an update of customer data will be presented. Introduction Introduction Columns are objects: Rows are represented: Authorization cell: Advantages Quiz Objects/Tables/Files, etc. Programs/Forms Intersection of a Row and a Column Advantages: 1) Overview of system. May Answers questions such as which are the most difficult programs to implement. 2) Maintenance Tool. When we modify a table, we know which form to go in and alter. 3) Security; helps implement security features as to prohibit access that are not explicitly allowed in the matrix. . Object Each individual operation (C, R, U, or D) should have a different hotlink and should display a different message/operation Introduction Event mouseclick mouseclick Action Displays message on the right. For example, if C in Access Cell Categories/Categories is clicked, the “Categories Form Creates a new row in Categories table.”. Show a categories table with a new row being created. Displays message on the right. Columns are objects: Objects/Tables/Files, etc. Rows are represented: Programs/Forms Authorization cell Intersection of a Row and a Column Column, Rows and Authorizations will appear with a hotlink. If you click on Columns, all the Tables will be highlighted. If you click on Rows, all rows will be highlighted. If you click on authorization cell, all authorization cells will be highlighted.= Advantages mouseclick Displays message on the right: Advantages: 1) Overview of system. May Answers questions such as which are the most difficult programs to implement. 2) Maintenance Tool. When we modify a table, we know which form to go in and alter. 3) Security; helps implement security features as to prohibit access that are not explicitly allowed in the matrix. Quiz mouseclick Starts a quiz with. Below are the description of each question 1) Which is the hardest Form/Program to Implement ? 2) When we modify the Customers a datatype in the customers table, what 3) 3) Forms/Programs may need modification ? 4) The Orders Form/Program accesses how many tables ? 5) The Employees Table is accessed by how many programs ? Figure 2. Integrity Matrix 2.3 Row Level Security Row level security is a fundamental database concept. It is a very common practice to restrict user access to data such that, for instance, a user is only able to view or modify the row or rows of data that correspond to them. For instance, when a student registers for a course, they should only be able to access their own personal information. A common way to implement row level security is through the use of views. A prototype animation depicting the construction of views is shown in Figure 4. In a data window, table data is shown as well as the SQL code for creating a view. In the input window, a user is able to make a choice from a dropdown box. This choice is used to restrict the data which will be displayed. The output window displays the results of the view given the selections made by the user. Figure 4. Row Level Security via a View Initial Screen: The window on the top left with Students Data Table and Student_View is displayed. A login window is displayed on the left (usename and password through drop down buttons). Usernames: Smith, Knight, Brown, Jones, Garcia, Taylor. Object Ok button of User Login Event mouseclick mouseclick Action Displays the view that corresponds to the respective user. 2.4 SQL Injection SQL injections are a major security threat. They embody one of the most important security issues -- risks inherent to non-validated user input. A SQL injection exploits a vulnerability in a database through the passing of malicious code in a SQL query/command. The vulnerability occurs primarily because of the features of the SQL language that allow such things as embedding comments using double hyphens ‘- -‘, concatenating SQL statements separated by semicolons and the ability to query metadata from database data dictionaries. The manipulation is to ‘trick’ the database into running code that is not intended for a particular situation and SQL injections occur when SQL queries are created dynamically using user input. Students need to build an understanding of and an appreciation for unintended consequences that might arise as more access to data contained in databases is being made available over public networks such as the Internet. There are many ways that a SQL injection might be constructed so as an instructional aide, a simple set of concrete animations examples might prove to be most useful in explaining how an this type of vulnerability works. The animation scenario chosen for this demonstration exemplifies a commonly published SQL injection from a login web page. Figure 5. Valid User Input This example depicts what might occur when a login process is employed on a web page connected directly to a SQL server database. The web page allows a user to input text and that text is then used to build a query executed against a database. If a malicious user enters malformed data into the textbox which changes the nature of the query, they have, in essence, found a way to either gain access to information (that he/she doesn’t have privilege to access) or delete or alter data in the back-end database. In this case, the intended use of the web form is to validate userentered data against a username and password in the database. A dynamically created SQL statement is used to search the database for matching records. Valid usernames and password combinations are authenticated and the user is permitted access to the system. Users who enter an invalid username and password are not authenticated. However, a malicious user can enter the following malformed text into the username textbox to gain access to the system without having to know either a valid username or password: ' OR 1=1 -- This hack works because the application generates a dynamic query that is formed by concatenating fixed strings with the values entered by the user. For example, the model SQL code might be: SELECT Count(*) FROM Users WHERE UserName = 'contents of username field' AND Password = 'contents of password field' When a user enters a valid username, such as ‘Mary’ and a password of ‘qwerty’ then the SQL query becomes: SELECT Count(*) FROM Users WHERE UserName=’Mary’ AND Password=’qwerty’ However, when a malicious user enters the following as a username: ' OR 1=1 -- the SQL query becomes: SELECT Count(*) FROM Users WHERE UserName=’ OR 1=1 -AND Password=’’ The expression 1 = 1 is always true for every row in the table, and OR will always return true if one of the expressions is true. The double hypens comment out the rest of the SQL query string. This query will return a count greater than zero, assuming there is at least one row in the users table, resulting in what appears to be a successful login. In fact, it is not. The malicious user gained access to the system without having to know either the username or password. Figure 6. Malicious User Input The animation for this example uses four windows: an input window, a code window, an output/results results window and a message window as depicted in Figures 5 and 6. It also includes a ‘Next’ button and a ‘Reset’ button. As is common practice in the ADbC animations, the user controls the pace of the animation with the next button. The user-interface window presents a sample web page containing two input fields. Dropdown boxes are used for input rather than textboxes to constrain user choices. One dropdown box contains a short list of potential usernames and the other a short list of potential passwords. Included in the list is the suspect string ' OR 1=1 - -. Users make a selection from the username and password dropdown boxes and then press the ‘Next’ button. Each time the Next button is clicked, the instruction in the code window is executed, changing the results in the output window when appropriate and providing information in the message window. The Reset button resets the animation to its beginning state. Figure 5 shows an example of correctly-entered user data and Figure 6 demonstrates the entry of a malicious entry string. 2.5 Inference A subtle vulnerability found within database technologies is inference, or the ability to derive unknown information based on retrieved information. This often occurs when doing on-line analytical processing of data with statistical databases such as census data. The problem with inference is that there are no ideal solutions to the problem. The only recommended solutions include controls related to the queries (suppression) or controls related to individual items in a database (concealing). In other words, data values of sensitive queries are either not provided or answers given are close but not exact preventing the user from obtaining enough information to make inferences. Neither of these represent ideal solutions as they are restrictive in nature. However, it is important for students to understand the risks of inference and how it might occur. Inference often happens in cases where the actual intent is for users to generate or view aggregate values, but not have access to individual data items. However, given the fact that the users are exposed to information about the data, they are sometimes able to infer individual values. Take for example a scenario where a user is asked to summarize organizational salary data averaged across specific criteria (i.e., salary averaged by gender). This same user knows particular information about someone in the organization, for example, that Goldberg is a female and has 11 dependents. Based on inferences that can be made, this user is able to discover Goldberg’s salary. The animation for this scenario is depicted in Figure 7. The data window displays the data contained in the employee table. The input window depicts the construction of the requested or allowed query to ascertain salary averages and also depicts the query which is built based on inferences. The output window displays the resulting output and a message window describes the event. Figure 7. Inference Scenario 3 CONCLUSION Many database topics are difficult to convey through traditional teaching methods such as textbooks or classroom lectures. Database security is one of those areas. We have proposed a series of animations that we believe will facilitate the teaching of database security concepts. These animations are part of an Animated Database Courseware project, initially funded by the NSF, designed to supplement existing database textbooks and other instructional materials. Incorporating the use of animations in the instructional process helps to enhance and enrich the standard presentation of important concepts. Instructors can use the animations to present new material with greater richness and flexibility and students can use the animations to reinforce concepts learned in class. The ADbC project is an ongoing initiative. The first phase focused on providing support for fundamental database concepts such as database design, SQL and transaction processing. As the project goes forward more advanced topics including database security are being added. Areas identified for inclusion in the database security module include integrity, application security (SQL injection and buffer overflow), database security (row and column level security using views and triggers), encryption and auditing. As presented in this paper, prototypes of animations related to referential integrity, integrity and security matrices, row level security, SQL injection and inference were demonstrated. The amount of information that students need to learn in any computing technology continues to increase. It was only a few years ago that database security was not included as a major topic in introductory database courses. The issues surrounding computer security are well publicized and the need to mitigate risks that arise as more data is retained in databases accessible over the Internet is known. However, it is still challenging to add another topic into the curriculum. The purpose of the ADbC is to address this issue by providing instructional support for the teaching of this important topic. Our preliminary research into the instructional effectiveness of this medium has been positive. We hope to extend this positive outcome to the database security animations by using an iterative approach for development and evaluation. 4 REFERENCES [1] Entity and Referential Integrity Issues in Multilevel Secure Database Management Systems. NCSC Technical Report -005. Volume 2/5 Library No. S-243,039. 1996. [2] George, B. and Valeva, A. A database security course on a shoestring. In Proceedings of the Technical Symposium on Computer Science Education (SIGCSE ’05), Houston, TX, March 2006. [3] Guimaraes, M. The Kennesaw Database Courseware (KDC): strong points, weak points, and experience using it in a classroom environment. J. Comput. Small Coll. 21, 3 (Feb. 2006), 91-96. [4] Guimaraes, M. Mattord, H. and Austin, R. Incorporating security components into database courses. In Proceedings of the Information Security Curriculum Development Conference (InfoSecCD '04), Kennesaw, GA, September 2004. [5] Naps, T. L., Rößling, G., Almstrum, V., Dann, W., Fleischer, R., Hundhausen, C., Korhonen, A., Malmi, L., McNally, M., Rodger, S., and Velázquez-Iturbide, J. Á. 2002. Exploring the role of visualization and engagement in computer science education. In Working Group Reports From ITiCSE on innovation and Technology in Computer Science Education (Aarhus, Denmark, June 24 - 28, 2002). ITiCSE-WGR '02. ACM Press, New York, NY, 131-152. [6] Srinivasan, S. and Kumar, A. Database security curriculum in InfoSec program. In Proceedings of the Information Security Curriculum Development Conference (InfoSecCD '05), Kennesaw, GA, September 2005.