{"_id":"55dc9aa9c755b63700dc841d","__v":26,"githubsync":"","project":"55db8f8f1a91690d007ad975","category":{"_id":"55db8f901a91690d007ad979","__v":10,"project":"55db8f8f1a91690d007ad975","version":"55db8f901a91690d007ad978","pages":["55db8f911a91690d007ad97b","55db92ffade8080d00c73833","55dc71fa7fa0290d00559111","55dc728900a8811900c230d1","55dc75a700a8811900c230e5","55dc764400a8811900c230eb","55dc7a2f6f16451700843e25","55dc977f6cce01230001ec4b","55dc98abc755b63700dc840f","55dc9aa9c755b63700dc841d"],"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-08-24T21:41:36.606Z","from_sync":false,"order":0,"slug":"general","title":"Getting Started"},"parentDoc":null,"user":"55dc702d7fa0290d00559106","version":{"_id":"55db8f901a91690d007ad978","project":"55db8f8f1a91690d007ad975","__v":17,"createdAt":"2015-08-24T21:41:36.034Z","releaseDate":"2015-08-24T21:41:36.034Z","categories":["55db8f901a91690d007ad979","55db9856b3d6540d00886426","55dc751b00a8811900c230e3","55dc766255be9f21004ee250","55dc769200a8811900c230ed","55e4c701177b6e0d003330fa","55f4915caf0bc71900a53130","55f491b2be9c2b2100f0635d","560b22739c7be70d00100bd8","57488c53e8c6a420000b729c","574cefd95953e20e00f40f9f","5798edfd7700d30e00ad250c","579ac88234b5fd0e00b9e140","57c81c6d690c200e0047b72e","57d9b8fbda17c30e003897f1","57d9b90e608ea00e00f358d8","57d9b91cda17c30e003897f4"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-08-25T16:41:13.813Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"settings":"","results":{"codes":[]},"auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"IMMUNIO is enabled by including the agent (a library) into your application. When your application starts, the IMMUNIO library performs the following functions:\n\n  * Detect which other components make up the application; templating engines, database drivers, session middleware, authentication libraries, and more.\n  * Insert hooks around detected components, which allow the agent to inspect the data entering these components, as well as the results returned by them.\n\nEvery time a web request hits your application, the hooks feed data collected into its rules processor. The rules processor determines inline whether there are signs of an attack or attacker and take action accordingly (block, alert, etc.). Finally, out-of-band from end-user requests, the agent will send important information (attacker username, type of attack, payload, etc.) to IMMUNIO and display that information in the dashboard.​\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"More powerful rules engine to determine attacks and attackers\"\n}\n[/block]\nMost RASP products instrument the VM/Runtime, or the Application Server (using extension mechanisms such as Java Server Filters or IIS DLLs). Once instrumented, they will either perform taint-analysis or pattern-matching, or a combination of both.\nUnfortunately, both of these approaches are limited in terms of:\n\n* Accuracy as defined by false positive and false negative numbers\n* Complexity in terms of effort required for manual configuration, such as whitelist modification and rule creation\n* Limited scope of threat detection\n* Limited support for runtimes or configurations\n\nIMMUNIO takes a different approach by instrumenting the application from within and executing complex and deterministic algorithms that require less (in most cases, zero) configuration or tuning. In doing so, IMMUNIO is able to outperform other RASP products in the areas outlined above.\n\nIMMUNIO does not rely on tokenization, whitelists, or blacklists to provide OS Command Injection detection/protection. Instead, the agent is able to identify all the areas in the application that call out to the Operating System and protect them using an algorithm that parses the shell command, and look for signs of injection when the syntax tree changes.\n\nIMMUNIO instruments the authentication libraries used by an application, and as a result, is able to detect a number of attacks on usernames and passwords. While these attacks cannot be detected by taint analysis, they are still a very common means of exploitation. In addition, IMMUNIO can detect and protect against platform-specific features such as those for Ruby on Rails, like Mass Assignment and YAML Serialization exploits.\n\nIn summary, IMMUNIO covers a much wider range of attacks than other RASP solutions, including those that are not generic, but specific to particular platforms. It does so with a high degree of accuracy and requires almost no configuration or maintenance. Because it operates not only at the application server level, but within the protected application, it can be deployed on micro-services running on the back end as well as public-facing web applications.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"CAPTCHA Mitigation\"\n}\n[/block]\nIMMUNIO offers an automatic CAPTCHA mitigation to protect your app from persistent attackers.\n\nWhen IMMUNIO detects an attacker, it checks the app settings to see what mitigation has been enabled. If CAPTCHA is enabled, the attacker’s IP address is pushed out to all agents for that app. When that attacker makes another request, a CAPTCHA challenge is returned to the attacker.\n\nIf the user solves the CAPTCHA correctly, that user is issued a signed cookie with a unique ID. All following requests contain the valid cookie, so they bypass the CAPTCHA protection. Other users from the same IP address will continue to see a CAPTCHA until they solve it. This allows IMMUNIO to track each user behind a suspect IP separately. Attackers are blocked, but normal users can browse freely.\n\nIf an attacker solves the CAPTCHA, then continues attacking the protected app, IMMUNIO will revoke the signed cookie, which will force another CAPTCHA. This dramatically disrupts automated attacks.\n\nWhen a cookie is issued, it is tied to the IP address that solved the CAPTCHA. This prevents one signed cookie from being distributed to a large botnet to defeat the CAPTCHA mechanism. For this reason, it is important that the IMMUNIO CAPTCHA service sees the same IP address as the protected app. The Load Balancer configuration must be correct, to ensure the Agent is seeing the correct end user IP. If you connect to your app server through the private network, this can also cause difficulties, as the IMMUNIO CAPTCHA service may only be seeing your public facing IP. If you consistently get the CAPTCHA challenge page, please contact [support:::at:::immun.io](mailto:support@immun.io) for assistance.","excerpt":"","slug":"how-does-it-work","type":"basic","title":"How does IMMUNIO work?"}

How does IMMUNIO work?


IMMUNIO is enabled by including the agent (a library) into your application. When your application starts, the IMMUNIO library performs the following functions: * Detect which other components make up the application; templating engines, database drivers, session middleware, authentication libraries, and more. * Insert hooks around detected components, which allow the agent to inspect the data entering these components, as well as the results returned by them. Every time a web request hits your application, the hooks feed data collected into its rules processor. The rules processor determines inline whether there are signs of an attack or attacker and take action accordingly (block, alert, etc.). Finally, out-of-band from end-user requests, the agent will send important information (attacker username, type of attack, payload, etc.) to IMMUNIO and display that information in the dashboard.​ [block:api-header] { "type": "basic", "title": "More powerful rules engine to determine attacks and attackers" } [/block] Most RASP products instrument the VM/Runtime, or the Application Server (using extension mechanisms such as Java Server Filters or IIS DLLs). Once instrumented, they will either perform taint-analysis or pattern-matching, or a combination of both. Unfortunately, both of these approaches are limited in terms of: * Accuracy as defined by false positive and false negative numbers * Complexity in terms of effort required for manual configuration, such as whitelist modification and rule creation * Limited scope of threat detection * Limited support for runtimes or configurations IMMUNIO takes a different approach by instrumenting the application from within and executing complex and deterministic algorithms that require less (in most cases, zero) configuration or tuning. In doing so, IMMUNIO is able to outperform other RASP products in the areas outlined above. IMMUNIO does not rely on tokenization, whitelists, or blacklists to provide OS Command Injection detection/protection. Instead, the agent is able to identify all the areas in the application that call out to the Operating System and protect them using an algorithm that parses the shell command, and look for signs of injection when the syntax tree changes. IMMUNIO instruments the authentication libraries used by an application, and as a result, is able to detect a number of attacks on usernames and passwords. While these attacks cannot be detected by taint analysis, they are still a very common means of exploitation. In addition, IMMUNIO can detect and protect against platform-specific features such as those for Ruby on Rails, like Mass Assignment and YAML Serialization exploits. In summary, IMMUNIO covers a much wider range of attacks than other RASP solutions, including those that are not generic, but specific to particular platforms. It does so with a high degree of accuracy and requires almost no configuration or maintenance. Because it operates not only at the application server level, but within the protected application, it can be deployed on micro-services running on the back end as well as public-facing web applications. [block:api-header] { "type": "basic", "title": "CAPTCHA Mitigation" } [/block] IMMUNIO offers an automatic CAPTCHA mitigation to protect your app from persistent attackers. When IMMUNIO detects an attacker, it checks the app settings to see what mitigation has been enabled. If CAPTCHA is enabled, the attacker’s IP address is pushed out to all agents for that app. When that attacker makes another request, a CAPTCHA challenge is returned to the attacker. If the user solves the CAPTCHA correctly, that user is issued a signed cookie with a unique ID. All following requests contain the valid cookie, so they bypass the CAPTCHA protection. Other users from the same IP address will continue to see a CAPTCHA until they solve it. This allows IMMUNIO to track each user behind a suspect IP separately. Attackers are blocked, but normal users can browse freely. If an attacker solves the CAPTCHA, then continues attacking the protected app, IMMUNIO will revoke the signed cookie, which will force another CAPTCHA. This dramatically disrupts automated attacks. When a cookie is issued, it is tied to the IP address that solved the CAPTCHA. This prevents one signed cookie from being distributed to a large botnet to defeat the CAPTCHA mechanism. For this reason, it is important that the IMMUNIO CAPTCHA service sees the same IP address as the protected app. The Load Balancer configuration must be correct, to ensure the Agent is seeing the correct end user IP. If you connect to your app server through the private network, this can also cause difficulties, as the IMMUNIO CAPTCHA service may only be seeing your public facing IP. If you consistently get the CAPTCHA challenge page, please contact [support@immun.io](mailto:support@immun.io) for assistance.