[gnso-rds-pdp-wg] JSON Flaws

Tue Jun 7 20:32:53 UTC 2016

Here are a few additional possible technical requirements for a new data collection system using JSON. I hope this is all relevant, as the learning curve is quite steep right now, and I haven't been able to read enough about all the tools used by a web/application developer that are mentioned below.  
1. Authentication flags and privilegeescalation

Since applications havetheir own access-control lists and privileges, if the implementation of theauthorization is weak, it opens up vulnerabilities that can be exploited, suchas accessing another's content or becoming a higher-level user with greaterpermissions. 

[SM-D1-R01]Identifying parameter names that have something to do with ACL/permission thatcould become a target, and the tester can use fuzzing tools to try and changebit patterns or permission flags, which may show the point at whichexploitation, escalating privileges or bypassing authentication can be achievedby an attacker.

2. Critical parameter manipulation and access to unauthorizedinformation/content

HTTPGET and POST requests are typically accompanied with several parameters whensubmitted to the application, typically in the form of name/value pairs, JSON,XML and so forth, but they can be tampered with and guessed by predicting. 

[SM-D1-R02] Tests for this lookfor easily guessable values and whether a parameter's value can be changed inorder to gain unauthorized access.

JSON XSRF Attacks

Allmodern web browsers implement Same Origin Policy (SOP) onwebsite content. This policy avoids one website from writing contents of framethat was issued from a different domain. This policy was implemented againstFrame Injection flaws. JSON CSRF exploits SOP by lifting one way restriction onwebsite and allows data from another website to execute on a different domain.This vulnerability is the result of flaw in SOP which treats JavaScript as code,not as data. According to browser policy, a code is allowed to be downloadedand executed over a client browser though the original source of the script isdifferent.

 JSON means Java Script ObjectNotification which is a data transfer format for JavaScriptinterpreters. It is used in AJAX based applications as an alternative tostandard XML data transfer format. In these applications, requests are madeusing XML Http Request to a server and the server returns data inJSON format. The received data is transferred on to the client side. SinceJavaScript is used to transmit data, then pure code SOP policy can getexploited to gain data generated by other applications. This data istransmitted back in the form of an array. Therefore, because of JSON, an XSRFattack can easily be executed on vulnerable site. It is quite clear that JSONCSRF attacks can be implemented over an AJAX based website which uses JSON datatransfer format against standard XML data transfer format.

 The following arepreventive measures that can be implemented against XSRF attacks.

 ·                    First of all, theapplication must implement all kinds of basic XSRF attacks.

·                    Always use unpredictableparameters for JSON objects.

·                    JSON XSRF attacks arepossible because the application can send XML Http Requests to retrieve JSONdata and it can only retrieve data by using the GET method; therefore, it isbetter to implement only the POST method as a countermeasure against JSON XSRF.

3. Developer's cookie tampering and business process/logicbypass

Cookiesare often used to maintain state over HTTP, but developers are not just usingsession cookies, but are building data internally using session-only variables.Application developers set new cookies on the browser at important junctureswhich exposes logic holes. The danger is that these cookies can be reverseengineered or have values that can be guessed or deciphered and attackers tryto identify these holes that are easy to exploit. 

[SM-D1-R03] Tests here typicallyinvolve analysis of cookies delivered during profiling, and looking for easilyguessable values, and whether a cookie value can be changed.

4. LDAP parameter identification and critical infrastructureaccess

A common use of LDAP is to provide a centralplace to store usernames and passwords. This allows many different applicationsand services to connect to the LDAP server to validate users. This has a majorbenefit that allows a central place to update and change user passwords. LDAP is becoming animportant aspect for large applications and may get integrated with"single sign-on" as well. Many infrastructure layer tools likeSiteMinder and Load Balancer use LDAP for both authentication andauthorization. LDAP parameters can carry business-logic decision flags that canbe abused or leveraged. Attackers can find business-layer bypasses and logicalinjections if the application is not doing enough validation. 

[SM-D01-R04] Tests for this focuson finding parameters linked with DAP, such as those taking email or usernames,which are prospective targets.

5. Business constraint exploitation

Theapplication's business logic should have defined rules and constraints, but ifpoorly designed, attackers can crawl them and browse through hidden fields andunderstand their context. 

[SM-D01-R05] Test hidden parametersand values, checking business-specific calls that can become a target andmanipulated.

6. Business flow bypass

Applicationsinclude flows that are controlled by redirects and page transfers. However, inmany cases, this flow can be bypassed, which can lead to an error condition orinformation leakage, which can help an attacker identify critical backendinformation. 

[SM-D01-R06] Test whether businessfunctionality and parameters can be tampered with through a proxy.

7. Exploiting client-side business routines embedded in JavaScript,Flash or Silverlight

Many business applications now run on richInternet application frameworks leveraging JavaScript, and in many cases thelogic is embedded in the client-side component. These can be reverse engineered.JavaScript can be debugged line by line to identify embedded logic. This couldinclude logic for cryptography algorithms, credential storage, privilegemanagement and other security. This may lead to possible exploits. 

[SM-D01-R06] To check for these kind of weaknesses, analyze the DocumentObject Model (DOM) and identify variables on a browser stack, and look forsuspicious values and parameters that can be exploited in DOM.

8. Identity or profile extraction

Acritical parameter in authenticated applications, the user's identity ismaintained using session or other forms of tokens. Attackers can identify thesetoken parameters in poorly designed and developed applications, opening up thepotential for abuse and systemwide exploitation. The token may only be using asequential number or guessable username. 

[SM-D01-R07] To test for this, lookfor parameters that are controlling profiles; if it's possible to decipher,guess or reverse engineer tokens.

9. File orunauthorized URL access and business information extraction

Businessapplications contain critical information in their features, in the files thatare exported and in the export functionality. Users can export their data in aselected file format (PDF, XLS or CSV) and download it. If this functionalityis carelessly implemented, it can enable asset leakage. 

[SM-D01-R08] To test for this, identifycall functionalities based on parameter names like file, doc, and dir, whichwill point you to possible unauthorized file-access vulnerabilities, and then agood test is doing basic brute force or guesswork to fetch another user's filesfrom a server.

10. Denial of service (DoS) with business logic

Denial-of-servicevulnerabilities for business applications pose serious issues because ifexploited, the application can be brought down for a length of time or at acritical juncture. Sometimes attackers can identify a loophole and try toexploit it during a DoS condition. There are no universal DoS attacks like TCPflooding on networking at the application layer, but in some cases, infiniteloops implemented in the application layer can lead to a DoS condition. 

[SM-D01-R09] Test applicationsagainst a threat model and provide defense at the application layer.

JSONWeb Token (JWT) libraries 

Critical vulnerabilities exist in several JSONWeb Token (JWT) libraries – namely the JavaScript and PHP versions – that couldlet an attacker bypass the verification step. Attackers could exploit one ofthose vulnerabilities, which abuses an asymmetric signingalgorithm, in some JWT libraries.

JWT is astandard that produces tokens between two parties. For example, a servercan produce an admin token, transferred in JSON, and signed by the server’skey. Clients can go on to use that token to verify the user is logged in as anadmin. The issue revolves around a public key confusion between systemssigned with the hash function HMAC and those signed with RSA. If a server isexpecting a token signed with RSA, but actually receives a token signed withHMAC, it will think the public key is actually an HMAC key. HMAC secret keysare supposed to be kept private, while private keys are well, public. In thisscenario if an attacker got access to a public key, through an API in someJWT libraries, they could use it as a token and the server would accept it. 

[SM-D01-R10] Toaddress the issue, verify that tokens with different signatures are set up tobe rejected either via a whitelisting or blacklisting mechanism. The servershould already know what algorithm it uses to sign tokens, and it’s not safe toallow attackers to provide this value. 

A separate issue, since fixed in manyJWT libraries, previously let attackers choose the way tokens are verified. Thisissue is rooted in the way that some libraries handled an algorithm knownas “none.” Tokens signed with “none” could have be acknowledged asvalid tokens with valid signatures. Attackers could modify tokens and sign themwith “none” instead of HMAC-SHA256, or HS256. The tokens would then appear“signed.” Attackers then could have gone on to attach their own payload to gainarbitrary account access on some systems. 

[SM-D01-R11] Fix the“none” issue by ensuring that token verification fails any tokens thatuse the “none” algorithm. Fix the attacker-controlled algorithm. JWTscan work across several languages, .NET, Node.js, Python, PHP, Java, Ruby, toname a few, and many remain vulnerable.

List of non-vulnerable libraries (partial): Theissue is fixed in the Node.js library and users should upgrade to 4.2.2, thelatest version. Jose Padilla, who maintains the Python build of the library,fixed the signature verification vulnerability in version 1.0.0 last month byadding support for an alg whitelist. The most recent version, 1.0.1, alsoincludes the fix. 

List of vulnerable libraries (partial): The PHPor JavaScript versions of the libraries remain vulnerable. Auth0 is instructingthose who run those versions of JWT in particular to seek out anothernon-vulnerable library until the issues are fixed or verified. The Ruby versionof the library is still vulnerable as well. 

ð A change to the specification, deprecating theheader’s alg field, would ultimately benefit the community. 

Best regards, Nathalie Coupet 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160607/49f7d83a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JSON Flaws.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 21324 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160607/49f7d83a/JSONFlaws.docx>