In this phase, the system will analyse the data that comes from the capturing data component. The phase will uses three checking components and these are as follows:
Chapter 4 - Architecture of DPF Framework
80 4.4.1. Input Checker Component
This component is the heart of the DPF as it determines the next step of DPF whether to proceed to the application normal processing component or the database observer component. Moreover, the input checker component will use the existing attack patterns that are prepared by the initial capture of user input component. The input checker component will analyse the user entry against existing attack, and the result is one of three possibilities:
The entry data is good, which means that the user input does not contain any SQL symbols or keywords that are used in existing SQL injection attacks, so the data will be passed to the application server for normal processing, and the user’s behaviour will be updated. The other possibility is that the entry data is bad, then the data will be rejected and the user’s behaviour will be updated and a message will be prepared to be sent to the user via the feedback component.
The last possibility is that the entry data is unknown; in this case the database observer component determines whether the entry data is bad or good according to effect these data have on the database. The database observer component checks the entry data by validating four conditions that determines whether the entry data is safe or not. The database observer component will be discussed in detail in the next section.
4.4.2. Database Observer Component
This component will check unknown entry cases which are not caught by the input checker component. The purpose of the database observer component is to determine
Chapter 4 - Architecture of DPF Framework
81
what exactly will happen to the database on the transaction of user input, and this will be done by monitoring the outcome of each database transaction.
The monitoring of the database transaction needs the web application developer because the database observer component needs the developer to specify the expected result of each transaction that is run by the web application such as, the table name, running command type, number of the expected records, and the user type.
The expected result of a database transaction will be compared with the runtime result. The comparison between the expected result and the runtime result is used to ensure that the database transaction is safe (if the runtime result is similar to what the developer expected) as shown in the Figure 4.4. In case of a unsafe transaction the database will be rolled back to the state before this unsafe transaction.
Therefore, the database observer has to monitor four conditions for each transaction;
TR Table =TE Table
TR Type =TE Type
TR R.No =TE R.No
TR User =TE User accept accept accept Normal processing accept Ro llb ac k No TR transaction at runtime TE expected transaction No No End DB Observer Start No
Chapter 4 - Architecture of DPF Framework
82
those conditions are specified by the web application developer as follows:
Transaction type at runtime is the same as the expected one specified by the developer. For example, if the transaction type at runtime is “Select” and the expected one is “Select” as well, then the database observer component will accept this transaction and continue. If they are different the database observer component will do a rollbackand prepare a feedback message for the user and update the user’s behaviour.
The transaction table name at runtime is the same as the expected one that is specified by the developer. For example, if the transaction table name at runtime is “users” and the expected table name is also “users” then the database observer component will accept this transaction and continue to the next step. If they are different then the database observer component will do a rollback and prepare a feedback message for the user and update the user’s behaviour.
The transaction record number at runtime is the same as the expected number that is specified by the developer. For example, the login page normally returns one record with the select statement, so if at runtime the select statement returns the same number (one record), then the database observer component will accept this transaction, otherwise it will be rejected and the database observer component will do a rollback and prepare a feedback message for the user and update the user’s behaviour.
Transaction user type at runtime is the same as the expected one that is specified by the developer. For example, the user tries to change the password at the change
Chapter 4 - Architecture of DPF Framework
83
password page then the user type should be same to the expected one. However, if the user tries to change another user’s password then the database observer component will catch this, then this transaction will be rejected and the database engine will do a rollback and prepare a feedback message for the user and update the user’s behaviour.
Note the database observer can only deal with recoverable transactions so no DDL (Data Definition Languages) commands like create, drop, and alter table, because the injected DDL commands cannot be recovered by a rollback command, so these transactions should already be rejected by the input checker component.
4.4.3. Output Checker Component
This component checks whether the message sent to the user is safe or not. The output checker will not analyse the response in the same way as the input checker, as it will block any message that contains details about the database structure or type because these types of messages are not safe. Moreover, the output checker will block unsafe messages using the library calls in the programming language which is employed during the development of the web application.