Security testing has to do a lot with one of the seven da Vincian principles - Sfumato (literally "Going up in Smoke") - a willingness to embrace ambiguity, paradox and uncertainty. A good security tester appreciates the existence of uncertainty, malice and chaos in the cyber world and tests software with a sense of respect for an attacker's thought process.

 

   While the goal of most software testing efforts is to verify that some feature works as specified, security testing is often about checking that some features appear to fail. Good security testers( a rare breed ) think from an attacker's view point. They thrive on breaking things. Experts on computer-security consider threat models as the fundamental basis of developing and testing secure code. One cannot build a secure system without understanding the threats to the system.

 

   In the book "Writing Secure Code", the authors define 'Threat Model' as a security-based analysis that helps people determine the highest level security risks posed to the product and how attacks can manifest themselves. The process of threat modeling can be generalized in four simple steps:

  1. Decompose application
  2. Determine threats
  3. Rank threats
  4. Mitigation

 

Determining threats (step 2) is most applicable to testing. Experts at Microsoft have categorized threats through the acronym STRIDE.

Spoofing identity

Tampering with data

Repudiation

Information disclosure

Denial of service

Elevation of privilege

 

In this series of blogs on security testing, I will cover testing for all six categories of threats, in subsequent posts.

 

Spoofing identity: (STRIDE)

 

What it means:

An attacker fakes his/her identity, by posing as another user to access the system. An extension of this threat will be, when an invalid server is allowed to pose as a valid server. A malicious user can fake an identity to access confidential information and/or engage in activities to further compromise the system.

 

Real-life examples:

Insecure authentication technique, such as HTTP authentication

 

Testing Technique:

  • Attempt brute forcing a user's credentials to gain access to the system. Check for the maximum number of login attempts allowed by the system. Look for the subtle error messages. Check if there are subtle error message changes after every brute force attempt, which may make spoofing feasible. Brute forcing a user's credentials can be mastered with experience. There are several tools available to attackers, which allow them to intelligently guess credentials. Ensure that minimum requirements for the semantics of a username or a password are not easily guessable.

 

  • Try forcing an application to use no authentication. Check if there is an option in the system, which allows access without authentication. Who has access to this option? Ensure that a non-administrator user does not have access to this option. Ideally a majority of systems should not has an option, which will allow access without authentication.

 

  • Check if a user is able to force a less secure "authentication protocol" to use a less secure legacy version?

 

  • Attempt to view a valid user's credentials in persistent storage or on the wire.

 

  • Check if cookies ( or other "security tokens" ) can be replayed to bypass an authentication stage.

 

Acknowledgements:

I would like to thank Michael Howard at Microsoft for his pragmatic approach towards evangelizing secure computing and his continuous support.

 

Disclaimer:
The concepts mentioned in this series on Security Testing are a compilation from different sources listed in the References section following every blog. I've made an attempt to summarize and compile latest concepts on security testing from experts.

 

References:

Books:
Writing Secure Code (Michael Howard and David LeBlanc)

How to break Software (James Whittaker)