We need to go deeper – Testing inception apps
We need to go deeper – Testing inception apps
When it comes to thick-clients, java applets, embedded devices or mobile apps – often, the idea is to forget about HTTP/S stack, plaintext POST parameters, and instead, implement a custom communication protocol. – Sending files for printing? Caesar cipher does not support full UTF-8, so use AES in ECB mode. – Malware attacking online banking? Even over HTTPS, double-encrypt POST parameters. If your clients are rich, use asymetric encryption, for better protection. – Planning SOAP WS? Use WCF Binary XML and put it in a START-TLS tunnel wrapped over a TCP connection.
Welcome to the world of application/x-inception-data content types, <meta charset=obscure> encoding and custom cryptography. Ideas that usually implement methods of ‘security by obscurity’. Once the outer layer of obfuscation is off, very often the server backend reveals simple access control issues, SQL query shells or code execution vulnerabilities. I will discuss real-world examples from enterprise solutions tests which require a bit more effort to allow tampering with data send from the client: – intercepting the traffic, bypassing NAC – decapsulating encryption and encoding layers – hooking into function calls, modifying packages – reverse-engineer proprietary protocols and encryption.
Head of Secure Development
