Jump to content

Search the Community

Showing results for tags 'json'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation

Found 2 results

  1. Bun, de cateva zile ma chinui sa construiesc o schema JSON decenta, pentru ca mai tarziu sa o pot manipula cat mai usor posibil. Scenario: User-ul va face un POST request cu un JSON care va arata de cele ai multe ori, asa: { "endpoint": "ep", "expression": { "field": "first_name", "operator": "EQUALS", "value": "Jack" }, "query_limit": "2" } Acum, in principiu, `endpoint` si `query_limit` vor fi mereu stringuri. Partea unde am eu probleme este `expression`. Exemplul de expresie de mai jos este minimal dar de ajuns pentru a explica ceea ce vreau sa fac. Acea expresie va face parte din clauza WHERE dintr-un query MSSQL. Spre exemplu, cea de mai sus va deveni: SELECT * FROM table WHERE first_name='Jack'; E de la sine inteles ca va exista o mapare intre operatorii din JSON si cei din MSSQL. In python, maparea aia se va face prin doua dictionare simple: LOGICAL_OPERATORS = { 'AND': 'AND', 'OR': 'OR' } COMPARISON_OPERATORS = { 'LT': '<', 'GT': '>', 'LTE': '<=', 'GTE': '>=', 'EQ': '=', 'NEQ': '!=' } The problem: Acum, partea la care intampin probleme este aceea de a dezvolta mai departe acel expression din JSON, astfel incat va putea suporta query-uri mult mai complexe. Vreau sa incerc sa acopar cat mai multe scenarii, asa ca am nevoie de o schema cat mai bine pusa la punct. Un exemplu: 1. Userul doreste ca `first_name` sa fie 'Jack' SI `last_name` sa fie 'Lola'. In cazul acela, JSON-ul ar putea sa arate asa: { "endpoint": "rfc", "expression": { "AND": [ { "field": "first_name", "operator": "EQUALS", "value": "Jack" }, { "field": "last_name", "operator": "EQUALS", "value": "Lola" } ] }, "limit": "2" } Exemplul de mai sus, va fi transformat intr-un SQL care va fi de forma: SELECT * FROM table WHERE first_name='Jack' AND last_name='Lola'; User-ul doreste ca `age` sa fie mai mic decat 17 SAU `age` mai mare decat 10 SI `first_name` sa fie 'Dick'. SQL-ul pentru descrierea de mai sus va fi de forma: SELECT * FROM table WHERE age > 10 OR age < 17 AND first_name='Jack'; Ceva idei pentru cum ar trebui sa arate JSON-ul in acest caz? Ceva care sa fie usor de adaptat pentru cazuri si mai complexe (va trebui sa generalizez toata treaba pentru ca asa cum stim toti care lucram in industria IT, userul e foarte inventiv cand vine vorba de edge cases). Thanks!
  2. Details ======= Product: F5 BIG-IP Application Security Manager (ASM) Vulnerability: Web Application Firewall Bypass Author: Peter Lapp, lappsec () gmail com CVE: None assigned Vulnerable Versions: Confirmed 11.4.0, 11.4.1. Should apply to all releases. Fixed Version: None Summary ======= The F5 ASM is a web application firewall designed to protect web applications from attacks. Due to the way that the system processes JSON content, it's possible to bypass the ASM using a crafted request to a URL that processes both JSON and regular URL encoded requests. The vendor has acknowledged that this is an issue and has indicated that a fix will be released sometime in the future, but doesn't have a time frame and it's not a priority. I decided to release the details so anyone with a vulnerable configuration is aware of the risk and can act accordingly. Technical Details ================= The problem is that the ASM's JSON parser does not normalize URL encoded content. So it will block <script>, but not %3cscript%3e. This is fine unless you have a JSON profile applied to a URL that also processes normal x-www-form-urlencoded POST requests. In this case, it's possible to trick the ASM into thinking the request is JSON, URL encode your payload, and slip it through to the application. Granted, this bypass is limited to a specific configuration, but it's really not that uncommon to have a JSON profile applied to a URL that also processes other data. Possible scenarios include a generic JSON catchall, one automatically created by the policy builder, or you may have a web application that uses parameter based navigation (page=json goes to one page, page=search goes to another). In any case, if you have a JSON profile applied to a URL that also handles POST requests with x-www-form-urlencoded content, you're vulnerable. First, in order to bypass the ASM, you have to trick it into thinking the request content is JSON. In F5's documentation (https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-11-4-0/14.html), they recommend matching *json* in the Content-Type header. This is easily tricked by setting the header to "Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json". I then tested setting it to only match on application/json, but that was still tricked by dual content-type headers: Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Type: application/json The application (running on Tomcat) processed the request as urlencoded, but the ASM processed it as JSON. >From here, passing through a malicious payload depends on the violations that are enabled on the security profile. If Malformed JSON is NOT enabled, you can just tag "json" onto the end of the content header(or double the header), URL encode special characters in your payload and send it away. In this case, a request like the following would not be blocked: POST / HTTP/1.1 Host: x.x.x.x Connection: keep-alive Content-Length: 168 Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json search=%3cimg+src%3dx+onerror%3alert%280%29%3e If Malformed JSON violations are enabled, then the payload has to be valid JSON. A request like the one below will get past that. It's not pretty but it works. This request will get past the ASM with all the bells and whistles enabled. POST / HTTP/1.1 Host: x.x.x.x Connection: keep-alive Content-Length: 168 Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json {"junkparam=&search=%3cimg+src%3dx+onerror%3dalert%280%29%3e&junkparam2=":"junk"} The ASM parses that as JSON and it is well formed so there aren't any errors. But the application is processing it as x-www-form-urlencoded so {"junkparam is just treated as a regular parameter name and the second parameter with the payload in it gets through. The last parameter is there just to close out the JSON format. Also, because JSON profiles don't check for meta characters in parameter names, it doesn't trigger an Illegal meta character in parameter name violation. If the payload looked like this {"param":"junkparam=&locationFilter=%3cimg+src%3dx+onerror%3dalert%280%29%3e&junkparam2="} then it would still get through but only if the illegal meta character in value violation was not set to block. Right now there is no fix for this issue and I haven't been able to find a way to block a request like the one above from getting through. I consulted F5's engineers and they said this was by design and there's no way to block it as of now. There will be a fix for this in the future, but until then make sure that your ASM profiles are as explicit as possible and you have compensating security controls for any URLs that this bypass would apply to. It's just another reason not to use a WAF as a band-aid for a vulnerable application! Feel free to contact me if you have any questions or additional information to add to this. Timeline ======== 1/19/2015 - Reported the issue to the vendor 2/26/2015 - The vendor confirms that it's a valid problem but are not going to release a fix in the near term. 3/13/2015 - Vendor product development creates ID 511951 to track the problem and consider adding a fix in a future major release. 5/5/2015 - Released info to FD. Source
×
×
  • Create New...