On Tue, Aug 22, 2017 at 4:44 PM, Gayan Chamara <[email protected]> wrote:
> 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 > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
