{"_id":"55dc79db55be9f21004ee25e","__v":14,"category":{"_id":"57d9b8fbda17c30e003897f1","project":"55db8f8f1a91690d007ad975","version":"55db8f901a91690d007ad978","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-09-14T20:54:19.794Z","from_sync":false,"order":4,"slug":"code-protection","title":"Code Protection"},"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"},"parentDoc":null,"githubsync":"","project":"55db8f8f1a91690d007ad975","updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-08-25T14:21:15.998Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":3,"body":"SQL injection vulnerabilities allow attackers to modify the structure of SQL queries in ways that allow for data ex-filtration or manipulation of existing data. SQL injection attacks are a vulnerability by which attacks abuse the SQL syntax in ways unexpected by the application. By executing certain database queries an attacker can extract information contained from other databases, tables, and even execute operating system commands.\n\nFor example, the following Rails code has a vulnerability that allows an attacker to delete arbitrary `User` records:​\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"User.delete_all(\\\"id = #{params[:id]}\\\")\",\n      \"language\": \"ruby\",\n      \"name\": \"Rails\"\n    }\n  ]\n}\n[/block]\nBy sending up an `id` parameter value of `1) OR 1=1--`, the attacker can delete all `User` records.\n\nIMMUNIO protects apps from SQL injection vulnerabilities by learning the expected structure of queries. For example, the above Rails code may execute the following query:​\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"DELETE FROM `users` WHERE (`id` = 5)\",\n      \"language\": \"sql\",\n      \"name\": \"SQL\"\n    }\n  ]\n}\n[/block]\nThe first time this query is executed we learn its structure. Subsequent queries are validated by comparing their structures against the first structure. If an attacker attempts to delete all records, as in the example above, the query structure will vary:​\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"-- The learned query's structure is:\\n-- \\\"DELETE FROM <identifier> WHERE (<identifier> = <value>)\\\"\\nDELETE FROM `users` WHERE (`id` = 5)\\n\\n-- This malicious query's structure is:\\n-- \\\"DELETE FROM <identifier> WHERE (<identifier> = <value>) OR <value> = <value> -- )\\\"\\nDELETE FROM `users` WHERE (`id` = 1) OR 1=1--)\",\n      \"language\": \"sql\",\n      \"name\": \"SQL\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Mitigation\"\n}\n[/block]\nWhen IMMUNIO detects an invalid query while in blocking mode, it will block the request before the query is executed to prevent any information from being manipulated or transmitted.​\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"FAQ\"\n}\n[/block]\n## How does IMMUNIO differentiate between different benign queries executed from the same place in the code?\nSome frameworks, Ruby on Rails being one example, allow for differing queries to be executed from the same line of code:​\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"users = User.where eye_color: :blue\\nif :::at:::gender\\n  users = users.where gender: @gender\\nend\\nusers.to_a\",\n      \"language\": \"ruby\",\n      \"name\": \"Rails\"\n    }\n  ]\n}\n[/block]\nThe structure of the query will vary depending on whether `@gender` is set.\n\nIMMUNIO intelligently follows the construction of ORM relations to ensure the proper query structure is learned and validated, even when conditionals may cause the structure to vary.\n\n## IMMUNIO is detecting SQL Injection attacks during normal usage of my app\nThis detection can​ occur when IMMUNIO is unable to differentiate between two different benign query structures for a single path through the app code. Usually it occurs during \"string-builder\" query construction:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"clause = \\\"eye_color = blue\\\"\\nif @gender\\n  clause << \\\" AND gender = #{ActiveRecord::Base.sanitize(@gender)}\\\"\\nend\\nUser.where(clause).to_a\",\n      \"language\": \"ruby\",\n      \"name\": \"Rails\"\n    }\n  ]\n}\n[/block]\nIn the above example, two different where clauses are constructed depending on whether `@gender` is set. While IMMUNIO can follow ORM relation modifications through conditionals, it is unable to monitor query construction through string manipulation.\n\nThere are two solutions for this issue:\n 1. Instruct IMMUNIO to \"learn\" additional SQL query structures in the IMMUNIO dashboard. Locate an instance of the threat and view its details. Click the **Learn** button to learn the query structure for future query structure verification.\n \n 2. Modify the application to construct clauses using ORM relation manipulation instead of string manipulation.​\n\nWhen SQLi alerts appear on the dashboard through normal and non-malicious usage of the application, click the “Learn” button on the threat UI to instruct Immunio to remember this particular SQL query structure for future reference, as shown below:\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/XPCvAJVmQ9GszeYqxwxu_Capture.PNG\",\n        \"Capture.PNG\",\n        \"479\",\n        \"285\",\n        \"#822d3f\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]","excerpt":"","slug":"sql-injection-sqli","type":"basic","title":"SQL Injection"}
SQL injection vulnerabilities allow attackers to modify the structure of SQL queries in ways that allow for data ex-filtration or manipulation of existing data. SQL injection attacks are a vulnerability by which attacks abuse the SQL syntax in ways unexpected by the application. By executing certain database queries an attacker can extract information contained from other databases, tables, and even execute operating system commands. For example, the following Rails code has a vulnerability that allows an attacker to delete arbitrary `User` records:​ [block:code] { "codes": [ { "code": "User.delete_all(\"id = #{params[:id]}\")", "language": "ruby", "name": "Rails" } ] } [/block] By sending up an `id` parameter value of `1) OR 1=1--`, the attacker can delete all `User` records. IMMUNIO protects apps from SQL injection vulnerabilities by learning the expected structure of queries. For example, the above Rails code may execute the following query:​ [block:code] { "codes": [ { "code": "DELETE FROM `users` WHERE (`id` = 5)", "language": "sql", "name": "SQL" } ] } [/block] The first time this query is executed we learn its structure. Subsequent queries are validated by comparing their structures against the first structure. If an attacker attempts to delete all records, as in the example above, the query structure will vary:​ [block:code] { "codes": [ { "code": "-- The learned query's structure is:\n-- \"DELETE FROM <identifier> WHERE (<identifier> = <value>)\"\nDELETE FROM `users` WHERE (`id` = 5)\n\n-- This malicious query's structure is:\n-- \"DELETE FROM <identifier> WHERE (<identifier> = <value>) OR <value> = <value> -- )\"\nDELETE FROM `users` WHERE (`id` = 1) OR 1=1--)", "language": "sql", "name": "SQL" } ] } [/block] [block:api-header] { "type": "basic", "title": "Mitigation" } [/block] When IMMUNIO detects an invalid query while in blocking mode, it will block the request before the query is executed to prevent any information from being manipulated or transmitted.​ [block:api-header] { "type": "basic", "title": "FAQ" } [/block] ## How does IMMUNIO differentiate between different benign queries executed from the same place in the code? Some frameworks, Ruby on Rails being one example, allow for differing queries to be executed from the same line of code:​ [block:code] { "codes": [ { "code": "users = User.where eye_color: :blue\nif @gender\n users = users.where gender: @gender\nend\nusers.to_a", "language": "ruby", "name": "Rails" } ] } [/block] The structure of the query will vary depending on whether `@gender` is set. IMMUNIO intelligently follows the construction of ORM relations to ensure the proper query structure is learned and validated, even when conditionals may cause the structure to vary. ## IMMUNIO is detecting SQL Injection attacks during normal usage of my app This detection can​ occur when IMMUNIO is unable to differentiate between two different benign query structures for a single path through the app code. Usually it occurs during "string-builder" query construction: [block:code] { "codes": [ { "code": "clause = \"eye_color = blue\"\nif @gender\n clause << \" AND gender = #{ActiveRecord::Base.sanitize(@gender)}\"\nend\nUser.where(clause).to_a", "language": "ruby", "name": "Rails" } ] } [/block] In the above example, two different where clauses are constructed depending on whether `@gender` is set. While IMMUNIO can follow ORM relation modifications through conditionals, it is unable to monitor query construction through string manipulation. There are two solutions for this issue: 1. Instruct IMMUNIO to "learn" additional SQL query structures in the IMMUNIO dashboard. Locate an instance of the threat and view its details. Click the **Learn** button to learn the query structure for future query structure verification. 2. Modify the application to construct clauses using ORM relation manipulation instead of string manipulation.​ When SQLi alerts appear on the dashboard through normal and non-malicious usage of the application, click the “Learn” button on the threat UI to instruct Immunio to remember this particular SQL query structure for future reference, as shown below: [block:image] { "images": [ { "image": [ "https://files.readme.io/XPCvAJVmQ9GszeYqxwxu_Capture.PNG", "Capture.PNG", "479", "285", "#822d3f", "" ] } ] } [/block]