SOFTware is HARD

I was once involved in reviewing our company’s application architecture to identify security risks and recommend possible mitigation solutions. Since every organisation has its own unique constraints, available resources, and risk appetite, the solution herein might not apply to other organisations. Nevertheless, this post showcases what one can do with UML to document and explain (pictorially) security flaws in application architecture. The as-is architecture follows. A detailed explanation follows: The system (under design) is a Java Enterprise Application that is deployed in AppSvr (Application Server) within the Internal zone. The deployed application consists of both HTML-based as well as SOAP-based services. The 2 WebSvr’s ([Apache] Web Server) in the DMZ act as proxies. There is a load-balancing appliance used to balance requests to the web servers. A request pool has been created on the appliance (WebPool). The (public) user would access the URL endpoint of the appli...

According to the HTTP specs, there are a number of HTTP codes used to redirect browser clients.   301 Moved Permanently : Permanent redirect. Document has moved permanently, future requests to use the redirected URL instead. Response is cacheable. Modern browsers change the HTTP method to a GET with the exception of IE (which preserves HTTP HEAD, DELETE method). 302 Found : Temporary redirect. To be superseded by 303 and 307. Response may be cached if headers allow for it. Most modern browsers treat this as 303 with the exception of IE (which treats it as 307). 303 See Other : Request should be redirected to a GET regardless of the original request method. The response must not be cached. Supported by all modern browsers. 307 Temporary Redirect : Temporary redirect. Request should be redirected to the redirected URL. The original request method is to be preserved and a POST request should be re-posted. Response may be cac...