Avoiding Logic Flaws
Just as there is no unique signature by which logic flaws in web applications can be identified, there is also no silver bullet with which you can be protected. For example, there is no equivalent to the straightforward advice of using a safe alternative to a dangerous API. Nevertheless, there is a range of good practice that can be applied to significantly reduce the risk of logical flaws appearing within your applications:
■ Ensure that every aspect of the application’s design is clearly documented in sufficient detail for an outsider to understand every assumption made by the designer. All such assumptions should be explicitly recorded within the design documentation.
■ Mandate that all source code is clearly commented to include the following information throughout:
# The purpose and intended uses of each code component.
# The assumptions made by each component about anything that is outside of its direct control.
# References to all client code which makes use of the component. nClear documentation to this effect could have prevented the logic flaw within the online registration functionality. (Note: “client” here refers not to the user end of the client-server relationship but to other code for which the component being considered is an immediate dependency.)
■During security-focused reviews of the application design, reflect upon every assumption made within the design, and try to imagine circumstances in which each assumption might be violated. Focus particularly on any assumed conditions that could conceivably be within the control of application users.
■ During security-focused code reviews, think laterally about two key areas: (a) the ways in which unexpected user behavior and input will be handled by the application, and (b) the potential side effects of any dependencies and interoperation between different code components and different application functions.
NEXT is..Attacking Other Users……………………………..,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
