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
- Reduce or eliminate front-end hideouts. i.e., eliminate or block chances of JavaScript injection.
- Secure potential intrusion points.
- Server-based XSS tunneling/brokering. Do not allow inter-site referencing to occur at browser/front-end.
- 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.
- Separation of data pattern validation from data content verification.
- Convenient and high visibility monitoring and pattern detection.
- Scriptable logging framework to allow quick cooking of detection filters of infringing/divergent patterns.
- Highly navigable monitoring/logging framework.
- Standardized logging convention. Labelled and categorized logging records, using standardized conventions.
- 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.
- 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.
- Well-defined cache strategies. Clear unused cache. Avoid caching unnecessarily.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Identify, eliminate race-conditions, thro redesign, or redeterminatize their characteristics.
- Use boxing and encrypted token on data-models to shield developers and processes that do not need to interpret the data from privacy information.
- 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.
- Highly optimized database queries. (e.g. well-known aversion - no select distinct in production code).
- 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.
- Run code check tools like FindBugs or PMD during builds to check for the extensively established bad coding patterns.
- 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
- Not allowing abnormality/exception handling to contribute to severity of intrusions. Design for fail-early.
- Having processes/services with as small granularity of action as efficiency would allow.
- Impede the effectiveness and efficiency of the process of attack as well as the process of producing/authoring attacks.
- Not allowing direct and convenient paths of access or progression for intrusions.
- Not providing intrusions with convenient ways to map the topology or responses of resources.
- Not allowing resources to further contribute intrusion or harassment.
- Not allowing visibility of data to accessors that handle but do not need to interpret the data.
- Not allowing data to be passed thro accessors that do not need to handle them.
- Preventing cross-talk between sessions.
- Using latency to reduce the number of attempts per minute.
- Confounding the intrusion. High visibility pattern for the developer, low visibility pattern for the hacker.
- Restricting and understanding application degrees-of-freedom, to be able to detect divergent and infringement patterns.
- Disallowing processes from doing more than required task.
- Having quick, efficient and effective detection system.
- Having quick, efficient and effective application update.
No comments:
Post a Comment