“…They implemented their solution through two components sensor and analyzer, the sensor collects traffic such as SQL quires its responses along with session variables and communicates with the analyzer, while the analyzer performs offline training by extracting SQL signatures and infers the set of invariants associated with signatures, In runtime, the analyzer evaluates incoming SQL queries and directs the sensor to block any violating queries, SENTINAL overcomes some of the limitations in BLOCK since it takes in consideration the persistent state in the database, additionally its visibility on SQL queries provides more capability in blocking attacks targeted database integrity. SENTINAL limitations include that the solution does not take into consideration NoSQL [36] database backend web applications and can only be applied to the traditional flat relational data model, moreover, it can only address traditional SQL queries that have the same patterns in different languages [37], moreover, can only be applied to specific web development languages and platforms, another limitation from the performance point of view that it introduces performance overhead in SQL response time because of the communication overhead between sensor and analyzer and the analysis time during which analyzer extracts SQL signature and evaluates the query, SENTINAL provides a slight enhancement on false positive rate comparing to BLOCK but still requires some additional techniques to ISSN: 2088-8708 suppress false positives. SENTINAL as well by design considers all unvisited paths or recorded invariants as attacks that also contribute to raising false positive rates, nevertheless, any change in the application structure or data layer will make the learned invariants invalid and require a new round of learning to avoid false positives and incorrect application wide blockage state.…”