# A Taxonomy for Security Flaws in Event-Based Systems
## 2 Background
### Event Attacks  
Event attacks represent the security problems caused by non-determinism in an EBS's event processing encountered by developers and end-users. Event attacks abuse, incapatice, and damage the system by exploiting event-based communication. Different types of event attacks have been identified throughout various domains, such as mobile and web apps [22; 24; 47; 52; 53; 54; 55; 56; 57; 58; 59; 60; 61]. The research to date has identified the following types of event attacks: _Spoofing_ (A1): A malicious component can send an event that spoofs a target component to exploit the target's functionality/data [22]; _Interception_ (A2): A malicious component can intercept an event that is supposed to be sent to other components and can send back inappropriate replies to make a target component malfunction or to exploit the target's functionality/data [22; 24]; _Eavesdropping_ (A3): A malicious component can eavesdrop on an event, which contains sensitive data, and is supposed to be open only for particular components [24; 60]; _Confused deputy_ (A4): A malicious component can indirectly access a target component, by accessing another component that has access to the target component, to exploit the target's functionality/data [47]; _Collusion_ (A5): Two or more malicious components can collude by exchanging events to exploit the functionalities or resources of a target component [47]; _Flooding_ (A6): A malicious component can send an overwhelming amount of events that makes a target component malfunction [55]; _Delaying_ (A7): A malicious component (or event broker) can intentionally delay a series of event interactions to make a target component malfunction [54]. We have formally defined each type of event attack as listed in Table 1.  
As event attacks are administered in the same manner as ordinary event exchanges and the malicious components disguise themselves as benign, it is difficult to identify and block event attacks. Preventing event attacks becomes more challenging especially when it is not possible to predict which component will compromise the system (e.g., as in the case in Android and J2 EE apps). For example, in Android systems, depending on the apps installed according to different users' preferences, the components comprising the system would be different. In such a case, as it is hard to guarantee that all components in the system are benign or safe from security threats, existing techniques that require pre-defined access distribution (e.g., role-based access control [39]) cannot be used to prevent event attacks. Although the Android system was designed to enforce permission-based access control [7], some types of event attacks can bypass the permission checks (i.e., confused deputy and collusion [61; 47; 53]). Putting a strict limitation on event communication may address some of these security threats, but it can reduce the flexibility of and hamper the benefits of the EBSs. Although developers are required to follow security policies while building a system, they tend to lack attention and make mistakes [62]. Practice has also shown that developers are often completely unaware of potential threats or underestimate the framework's capabilities, thus placing the responsibility on the end-users to protect themselves while using the system [63].