Hi all, This is to give you a quick update about the project. So far, In the XML side, I've considered many StAX and StAX-like parsers for the implementation. Support for threat protection features are vary from parser to parser. Please refer the following table for feature comparison,
FEATURE AXIOM WOODSTOX Java Default1 Depth Limiting ❌ ✓ ✓ DTD Disabling ✓ ✓ ✓ External Entity Disabling ✓ ✓ ✓ Element Count Limiting ❌ ✓ ✓ Attribute Count Limiting ❌ ✓ ✓ Attribute Length Limiting ❌ ✓ ❌ Entity Expansion Limit ❌ ❌2 ✓ Max Element Name Limit ❌ ❌ ✓ 1. Provided by com.sun.xml packages. Directly relying on this implementation is not recommended because it’s not part of the Java Standard. Breaking changes can be introduced in new versions. 2. Default limit of 100,000 exists but configurability is unknown According to above table, woodstox seems to be a good choice for the implementation but as ballerina uses axiom as its xml parser, it could be a problem. Please suggest your thoughts regarding this issue as well. I’ve already tested these libraries with ballerina native calls and I will be ready to implement these as soon as possible. ------------------------------ On the JSON side, I’ve considered using a schema to enforce limits on json payloads. Check the following schema for details (it’s not the final version) [image: Screenshot from 2017-08-22 12-30-10.png] <http://wiki.fasterxml.com/JacksonHome> Description of Properties Property Description Type Type of the json payload (object, number, array, etc) minProperties Minimum number of properties (keys) allowed in json payload maxProperties Maximum number of properties (keys) allowed in json payload “^.{1,4}” Key length should be within range 1 and 4 aditionalProperties Whether any additional properties allowed in json payload boundedString maxLength Maximum length of string values allowed in json payload minLenght Minimum length of string values allowed in json payload boundedNumber minimum Minimum value allowed for number values maximum Maximum value allowed for number values boundedArray minItems Minimum number of elements allowed in array type values maxItems Maximum number of elements allowed in array type values Json-Schema-Validator <https://github.com/java-json-tools/json-schema-validator/> which uses Jackson <http://wiki.fasterxml.com/JacksonHome> at it’s core can be used to validate json payloads against pre-defined set of constraints. Please suggest your ideas on these approaches and also if there are better ways than this those ideas will be very valuable as well. Thanks. On Mon, Jul 31, 2017 at 10:56 AM, Gayan Chamara <[email protected]> wrote: > Hi All, > > I’m working on a Threat Protection system for API Manager. The system will > responsible for detecting and preventing of xml and json based attacks on > API Manager gateway. > > How did APIM supported this so far? > > So far APIM users used custom mediators and handlers to handle this type > of requirements. > > Some of our users are using JSON, XML payload validation with the help of > handlers. But those are never shipped as first class features. Also they > were using new throttling feature to implement IP whitelisting policies, > header/query parameter based filtering etc. > > What is next? > > When APIM moving ahead with ballerina based gateway, we will ship some of > these common threat detection mechanisms as OOB features. > > Initial plan is to let users to plug threat detection policy in two > different levels as follows. > > 01. Global threat protection policy > > System administrator can use predefined policy set with specific > configurations. > > 02. Per API threat protection policy > > We need to allow users to add threat protection policy in API level with > specific parameters. For example one API may expect 100 sub-elements in > JSON payload while other API will allow only 10 sub elements in JSON > payload. These protection policies may depend on the API. > > > Initial List of Threats Identified > > - > > XML Bombs > - > > Canonicalization attacks > - > > Coercive Parsing (json/xml) > - > > XML External Entity Attacks > - > > SQL Injection > - > > Schema Poisoning (json/xml) > - > > Buffer overflows > - > > TCP/IP Based Attacks > - > > IP Address Spoofing > - > > TCP Sequence Number Prediction > - > > Port Scanning > - > > WSDL Scanning > - > > XML Routing Detours > - > > Network Eavesdropping > - > > Cross-site scripting > - > > Denial of Service (DoS) attacks > - > > Parameter Tampering > - > > HTTP Header Manipulation > - > > Form Field Manipulation > - > > Query string manipulation > > > List of Solutions Identified > > - > > Limiting the depth of xml and json > - > > Limiting the length of elements > - > > Limiting count of elements and number of items in json arrays > - > > Disabling external/embedded DTD parsing > - > > Disabling embedded schemas > - > > Disabling loading schemas from unauthorized locations > - > > Set correct permissions to local schema files (disallow write access) > - > > IP whitelisting/blacklisting > - > > Rate Limiting > - > > Escaping All User Supplied Input > > > > Design Details > > Number of User Interfaces is going to be added to the API Manager as admin > users should have a way to enable/disable/create threat protection policies. > > Threat protection system can be implemented as a Global level (which is > going to monitor all the API requests) mechanism or Per API mechanism > (Which will be applicable for specified APIs) mechanism. Whether the > initial implementation should be Global or per API, should be discussed. > > In addition to that, set of threats should be identified for initial > implementation of the system. Any other ideas or suggestions are also > welcome. > > PS: A detailed document about Threats on Web Services is attached below. > > Thanks & Regards, > > *Gayan Chamara* > > *Software Engineering Intern* > *WSO2* > > > *Email: [email protected] <[email protected]> * > > *Mobile : +94 71 7285827 <+94%2077%20767%201807>* > > <http://wso2.com/signature> > -- Regards, *Gayan Chamara* *Software Engineering Intern* *WSO2 Inc.* *Email: [email protected] <[email protected]> * *Mobile : +94 71 7285827 <+94%2077%20767%201807>* <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
