Choosing a Message/Channel Identifier on a Public/Multicast Channel
Attackers aware that more data is being fed into a multicast or public information distribution means can 'select' information bound only for another client, even if the distribution means itself forces users to authenticate in order to connect initially.
Doing so allows the attacker to gain access to possibly privileged information, possibly perpetrate other attacks through the distribution means by impersonation.
If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could change its identifier from a less privileged to more so privileged channel or command.
Using Unpublished Web Service APIs
An attacker searches for and invokes Web Services APIs that the target system designers did not intend to be publicly available. If these APIs fail to authenticate requests the attacker may be able to invoke services and/or gain privileges they are not authorized for.
Manipulating Writeable Terminal Devices
This attack exploits terminal devices that allow themselves to be written to by other users. The attacker sends command strings to the target terminal device hoping that the target user will hit enter and thereby execute the malicious command with their privileges. The attacker can send the results (such as copying /etc/passwd) to a known directory and collect once the attack has succeeded.
Cross Site Request Forgery (aka Session Riding)
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level.
This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.