Biblio
Now-a-days web applications are everywhere. Usually these applications are developed by database program which are often written in popular host programming languages such as C, C++, C\#, Java, etc., with embedded Structured Query Language (SQL). These applications are used to access and process crucial data with the help of Database Management System (DBMS). Preserving the sensitive data from any kind of attacks is one of the prime factors that needs to be maintained by the web applications. The SQL injection attacks is one of the important security threat for the web applications. In this paper, we propose a code-based analysis approach to automatically detect and prevent the possible SQL Injection Attacks (SQLIA) in a query before submitting it to the underlying database. This approach analyses the user input by assigning a complex number to each input element. It has two part (i) input clustering and (ii) safe (non-malicious) input identification. We provide a details discussion of the proposal w.r.t the literature on security and execution overhead point of view.
The impact of microarchitectural attacks in Personal Computers (PCs) can be further adapted to and observed in internetworked All Programmable System-on-Chip (AP SoC) platforms. This effort involves the access control or execution of Intellectual Property cores in the FPGA of an AP SoC Victim internetworked with an AP SoC Attacker via Internet Protocol (IP). Three conceptions of attacks were implemented: buffer overflow attack at the stack, return-oriented programming attack, and command-injection-based attack for dynamic reconfiguration in the FPGA. Indeed, a specific preventive countermeasure for each attack is proposed. The functionality of the countermeasures mainly comprises adapted words addition (stack protection) for the first and second attacks and multiple encryption for the third attack. In conclusion, the recommended countermeasures are realizable to counteract the implemented attacks.
Language-based information-flow control (IFC) techniques often rely on special purpose, ad-hoc primitives to address different covert channels that originate in the runtime system, beyond the scope of language constructs. Since these piecemeal solutions may not compose securely, there is a need for a unified mechanism to control covert channels. As a first step towards this goal, we argue for the design of a general interface that allows programs to safely interact with the runtime system and the available computing resources. To coordinate the communication between programs and the runtime system, we propose the use of asynchronous exceptions (interrupts), which, to the best of our knowledge, have not been considered before in the context of IFC languages. Since asynchronous exceptions can be raised at any point during execution-often due to the occurrence of an external event-threads must temporarily mask them out when manipulating locks and shared data structures to avoid deadlocks and, therefore, breaking program invariants. Crucially, the naive combination of asynchronous exceptions with existing features of IFC languages (e.g., concurrency and synchronization variables) may open up new possibilities of information leakage. In this paper, we present MACasync, a concurrent, statically enforced IFC language that, as a novelty, features asynchronous exceptions. We show how asynchronous exceptions easily enable (out of the box) useful programming patterns like speculative execution and some degree of resource management. We prove that programs in MACasync satisfy progress-sensitive non-interference and mechanize our formal claims in the Agda proof assistant.
The current evaluation of API recommendation systems mainly focuses on correctness, which is calculated through matching results with ground-truth APIs. However, this measurement may be affected if there exist more than one APIs in a result. In practice, some APIs are used to implement basic functionalities (e.g., print and log generation). These APIs can be invoked everywhere, and they may contribute less than functionally related APIs to the given requirements in recommendation. To study the impacts of correct-but-useless APIs, we use utility to measure them. Our study is conducted on more than 5,000 matched results generated by two specification-based API recommendation techniques. The results show that the matched APIs are heavily overlapped, 10% APIs compose more than 80% matched results. The selected 10% APIs are all correct, but few of them are used to implement the required functionality. We further propose a heuristic approach to measure the utility and conduct an online evaluation with 15 developers. Their reports confirm that the matched results with higher utility score usually have more efforts on programming than the lower ones.