Hi, I've been testing the initial implementation of Threat Protection system for fast several days. In initial testings following statistics were collected.
XML Performance Results JSON Performance Results As per above graphs, It was clear that in XML Threat Protection System, - Analyzer object instantiation time is much higher - Creating XML Factory object is also costly operation Similarly in JSON Threat Protection System, - Analyzer object instantiation time is higher compared to other activities *Solutions Identified* - Both json and xml object instantiation phase involves reading configurations via ServiceReferenceHolder. So it was decided to cache the configuration data for fast access. - In addition to that, JSON threat protection mechanism was changed from Schema based validation mechanism to JSON Stream parsing mechanism for better performance. After the modifications made to the system, following results were obtained, XML Performance Results JSON performance Results As it seems that XML System still has some performance issue. And I'll keep exploring areas where I can improve the performance and In the meantime your valuable ideas regarding the project are more than welcome. Thanks. Gayan. On Mon, Jul 31, 2017 at 10:48 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 728 5827 <+94%2071%20728%205827>* <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
