Patterns and Architectures to prevent and impede Harassment and Intrusions - Introduction

There is a wealth of information on the web describing in detail the types of intrusion and harassment.

There is also a set of rules viewable as OWASP.

The following set of rules, discusses programming/deployment patterns and architectures that are obstructive to harassment/intrusions, such as

1. Reduce or eliminate front-end hideouts. i.e., eliminate or block chances of JavaScript injection.
2. Secure potential intrusion points.
3. Server-based XSS tunneling/brokering. Do not allow inter-site referencing to occur at browser/front-end.
4. Encryption and information obfuscation.
• The less clarity of information is exposed, the less efficient will be the algorithm and process of attack, and the less efficient use of time by attack authors.
• Consciousness that encoding is not encryption (e.g. there is no shortage of developers who think Base64 is an encryption).
• Use random session validation tokens in exchanges between client and server. Perhaps, even per-request token.
5. Separation of data pattern validation from data content verification.
6. Convenient and high visibility monitoring and pattern detection.
7. Scriptable logging framework to allow quick cooking of detection filters of infringing/divergent patterns.
8. Highly navigable monitoring/logging framework.
9. Standardized logging convention. Labelled and categorized logging records, using standardized conventions.
10. Use Exception handling over functional error detection. Functional error detection introduces obfuscating logic that masks vulnerabilities in the code.
• Therefore use programming languages capable of expressing exceptions.
• Exception chaining should rethrow an extended class of the current exception rather than a wrapper for error traceability, if not re-throwing the same exception.
• Catch all Exceptions, even for pass-thro ones, in order to log them.
11. Lazy loading/processing. Do not load or commit resources until required - to preclude them from contributing to load-overwhelming attack, or making more resources available for attack.
12. Well-defined cache strategies. Clear unused cache. Avoid caching unnecessarily.
13. Transmit data-models not queries, scripts, commands or series of actions from front-end.
• Front-end developers should invalidate from input fields any script/code that is a language of a server-side system.
• e.g. of scripts/actions snippets to be detected and invalidated from input fields are JavaScript, SAS macros, SQL, LDAP actions, XPath query, JSP, URLs .
• e.g., if SAS is a middle-ware used along the chain of processing, then front-end developers should invalidate input that contains SAS macro language patterns, unless it is a page/state specifically secured to accept SAS macros.
14. Necessitate data transformation gates, at front-end handler. i.e., 
• decouple data-model between data received from incoming interface from the data to be handed to the back-end. 
• Use data-models that are completely different between the API and the internal processing.
• Use parameters, Enums or indirect references as much as possible at API, and then construct the data model and queries internally behind the API.
• These measures introduce additional impediment to injected SQL or JavaScript being persistently stored, and unleashed on other users/sessions.
15. Behaviour-driven development to define expected behaviour, for easy detection of unexpected behaviours.
• State-machine driven implementation to define expected states, for easy detection of unused or unexpected states.
• Use state-machine driven implementation to reduce use of if-then-else, and to facilitate error-free insertion/deactivation of states, events, actions and business rules.
• Granularized and state-machine managed page or state progression. Granularization will reduce the amount of processing per component, when a component is at the brunt of an attack.
• Use state-machine methodology to design, progress flow of granularized web forms/pages.
• Unused decoy states and buckets to trap and alarm intrusion attempts.
• Test-driven development, with test coverage for exploits, and diversions.
• Functional stateless web services components with well defined API, allows preclusion of side-effects.
• Well-defined orthogonal landscape of functional stateless web services and granularized API, to preclude/reduce frequencies of set of task done being larger than set of task required to be done. i.e, Reduce or eliminate chances of web services doing more than requested.
• Push all the state representation and transition up to the state-machine level, because that is what a state-machine is. All components should be stateless, immutably functional.
• Using UML will exhaustively define behaviour, use-cases, event-action sequence, API, states, and finally conveniently define the unit tests.
• Measure behaviour coverage in unit test coverage.
16. Optimally granularize front-end interface to do as little per request, but as much as efficiency needs possible.
• Therefore, granularize and break web forms/pages up into multiple page progressions.
17. Use include-only mode authorization and request handling. Do not use exclude-mode handling, to preclude unknown side-effects being exploited.
• Restrict access by roles.
• Where roles are given permissions not excluded from permissions.
18. Restrict patterns allowable for username, password and input fields.
• This will weed out code, script injection, enforce fail-early.
• This will also contribute to weeding out injected JavaScript from propagating into a persistently stored injection.
19. Non-acknowledgement or vague acknowledgement of access errors at access interface. Do not let your potential adversary have knowledge of the accuracy of their guessing.
20. Granularize authentication to slow down or impede auto-hacking bots.
• Multistage authentication, with significant but not inconveniencing latency. e.g., 10 second latency restricts hacking/breaking attempts to 6 per minute, but is not inconvenient to user.
• Introduce multiple factors like human interaction avenues to interrupt the authentication process.
• e.g. entering the phone number that is pre-registered.
• e.g. sending a token string to a phone that has to be keyed in at one stage.
• e.g. have username entry as one request page, and then password entry as the next request page.
• Only acknowledge any authentication failure at the end, without informing which stage of authentication had failed.
• Criticality of the resource will dictate how far the authenticating user should be inconvenienced.
21. Insulate against hash table collisions due to DoS attack with deluge of POST requests. Again by granulating the design of the state-machine.
• By breaking up a functionality into multiple components.
• Hence limiting the processing per attack request.
• Limiting the number of parameters per attack request.
• Limiting the amount of exposure of the hash table per attack request.
22. Quick turn-around life-cycle agile development to quickly identify, mitigate vulnerability. To reroute exception and relabel logging, to identify assured-benign exceptions from crowded out critical exceptions.
23. Identify, eliminate race-conditions, thro redesign, or redeterminatize their characteristics.
24. Use boxing and encrypted token on data-models to shield developers and processes that do not need to interpret the data from privacy information.
25. Highly/optimally normalized data-model and database schema. Do not access 1000 columns if process only needs 3 columns. Do not access unneeded records. Allowing highly optimized data query, retrieval and transmissions.
26. Highly optimized database queries. (e.g. well-known aversion - no select distinct in production code).
27. Applications or Web services should avoid accepting response URL, or triggering access of an URL.
• That URL may actually be targeting an internal resource, accessible only from behind the firewall
• All referenced URLs and APIs should be pre-validated, at build time.
• Any internally referencing URL should be within an allowed state of the application state-machine definition, and not received from external sources.
• Requests to reference preconfigured, prevalidated URLs thro parameters.
28. Run code check tools like FindBugs or PMD during builds to check for the extensively established bad coding patterns.
29. Use CI tools and maven/gradle to standardize build procedures, and deployment configuration.

The motivation of these techniques and patterns include but not restricted to

1. Not allowing abnormality/exception handling to contribute to severity of intrusions. Design for fail-early.
2. Having processes/services with as small granularity of action as efficiency would allow.
3. Impede the effectiveness and efficiency of the process of attack as well as the process of producing/authoring attacks.
4. Not allowing direct and convenient paths of access or progression for intrusions.
5. Not providing intrusions with convenient ways to map the topology or responses of resources.
6. Not allowing resources to further contribute intrusion or harassment.
7. Not allowing visibility of data to accessors that handle but do not need to interpret the data.
8. Not allowing data to be passed thro accessors that do not need to handle them.
9. Preventing cross-talk between sessions.
10. Using latency to reduce the number of attempts per minute.
11. Confounding the intrusion. High visibility pattern for the developer, low visibility pattern for the hacker.
12. Restricting and understanding application degrees-of-freedom, to be able to detect divergent and infringement patterns.
13. Disallowing processes from doing more than required task.
14. Having quick, efficient and effective detection system.
15. Having quick, efficient and effective application update.