Different Application Security Testing Tools: Major Classification

 Static Application Security Testing (SAST)

SAST tools can be thought of as white-hat or white-box testing, where the tester knows information about the system or software being tested, including an architecture diagram, access to source code, etc. SAST tools examine source code (at rest) to detect and report weaknesses that can lead to security vulnerabilities.

Source-code analyzers can run on non-compiled code to check for defects such as numerical errors, input validation, race conditions, path traversals, pointers and references, and more. Binary and byte-code analyzers do the same on built and compiled code. Some tools run on source code only, some on compiled code only, and some on both.

Dynamic Application Security Testing (DAST)

In contrast to SAST tools, DAST tools can be thought of as black-hat or black-box testing, where the tester has no prior knowledge of the system. They detect conditions that indicate a security vulnerability in an application in its running state. DAST tools run on operating code to detect issues with interfaces, requests, responses, scripting (i.e. JavaScript), data injection, sessions, authentication, and more.

DAST tools employ fuzzing too: throwing known invalid and unexpected test cases at an application, often in large volume.

Origin Analysis/Software Composition Analysis (SCA)

Software-governance processes that depend on manual inspection are prone to failure. SCA tools examine software to determine the origins of all components and libraries within the software. These tools are highly effective at identifying and finding vulnerabilities in common and popular components, particularly open-source components. They do not, however, detect vulnerabilities for in-house custom developed components.

SCA tools are most effective in finding common and popular libraries and components, particularly open-source pieces. They work by comparing known modules found in code to a list of known vulnerabilities. The SCA tools find components that have known and documented vulnerabilities and will often advise if components are out of date or have patches available.

Database Security Scanning

The SQL Slammer worm of 2003 exploited a known vulnerability in a database-management system that had a patch released more than one year before the attack. Although databases are not always considered part of an application, application developers often rely heavily on the database, and applications can often heavily affect databases. Database-security-scanning tools check for updated patches and versions, weak passwords, configuration errors, access control list (ACL) issues, and more. Some tools can mine logs looking for irregular patterns or actions, such as excessive administrative actions.

Interactive Application Security Testing (IAST) and Hybrid Tools

Hybrid approaches have been available for a long time, but more recently have been categorized and discussed using the term IAST. IAST tools use a combination of static and dynamic analysis techniques. They can test whether known vulnerabilities in code are actually exploitable in the running application.

IAST tools use knowledge of application flow and data flow to create advanced attack scenarios and use dynamic analysis results recursively: as a dynamic scan is being performed, the tool will learn things about the application based on how it responds to test cases. 

Mobile Application Security Testing (MAST)

MAST Tools are a blend of static, dynamic, and forensics analysis. They perform some of the same functions as traditional static and dynamic analyzers but enable mobile code to be run through many of those analyzers as well. MAST tools have specialized features that focus on issues specific to mobile applications, such as jail-breaking or rooting of the device, spoofed WI-FI connections, handling and validation of certificates, prevention of data leakage, and more.

Application Security Testing as a Service (ASTaaS)

As the name suggests, with ASTaaS, you pay someone to perform security testing on your application. The service will usually be a combination of static and dynamic analysis, penetration testing, testing of application programming interfaces (APIs), risk assessments, and more. ASTaaS can be used on traditional applications, especially mobile and web apps.

Momentum for the use of ASTaaS is coming from use of cloud applications, where resources for testing are easier to marshal.

Correlation Tools

Dealing with false positives is a big issue in application security testing. Correlation tools can help reduce some of the noise by providing a central repository for findings from others AST tools.

Different AST tools will have different findings, so correlation tools correlate and analyze results from different AST tools and help with validation and prioritization of findings, including remediation workflows. Whereas some correlation tools include code scanners, they are useful mainly for importing findings from other tools.

Test-Coverage Analyzers

Test-coverage analyzers measure how much of the total program code has been analyzed. The results can be presented in terms of statement coverage (percentage of lines of code tested) or branch coverage (percentage of available paths tested).

For large applications, acceptable levels of coverage can be determined in advance and then compared to the results produced by test-coverage analyzers to accelerate the testing-and-release process. These tools can also detect if particular lines of code or branches of logic are not actually able to be reached during program execution, which is inefficient and a potential security concern. Some SAST tools incorporate this functionality into their products, but standalone products also exist.

Application Security Testing Orchestration (ASTO)

While the term ASTO is newly coined by Gartner since this is an emerging field, there are tools that have been doing ASTO already, mainly those created by correlation-tool vendors. The idea of ASTO is to have central, coordinated management and reporting of all the different AST tools running in an ecosystem. It is still too early to know if the term and product lines will endure, but as automated testing becomes more ubiquitous, ASTO does fill a need.

Selecting Testing Tool Types

There are many factors to consider when selecting from among these different types of AST tools. If you are wondering how to begin, the biggest decision you will make is to get started by beginning using the tools. According to a 2013 Microsoft security study, 76 percent of U.S. developers use no secure application-program process and more than 40 percent of software developers globally said that security wasn't a top priority for them. Our strongest recommendation is that you exclude yourself from these percentages.

There are factors that will help you to decide which type of AST tools to use and to determine which products within an AST tool class to use. It is important to note, however, that no single tool will solve all problems. As stated above, security is not binary; the goal is to reduce risk and exposure.

Network Security Tools

Though they are not directly the part of Application Security domain, however without these fully implemented and running the application shall be prone to more and more risks. There is a separate post for list or types of network security tools.

Mockito Vs EasyMock - How to use and the difference in Unit Testing

What is mocking? 

A unit test should be independent of any external resources : database, message queue etc.

Ideally, a unit test should test only one class. Mocking is a best practice when testing an object which is linked to other objects.

Example : CompanyCreateTest should only test CompanyCreate

Mockito and EasyMock:

Both are java mocking libraries for Unit Testing, and follow the same model of

1. Mock external dependencies
2. Setup expectations
3. Run test
4. Verify results

Both of the above are equivalent in features and capabilities. The essential difference exists in their usage at point 3 and 4. EasyMock needs explicit replaying and verification of Mocks and Mockito doesn't. 

Similarities :

• Mocks concrete classes as well as interfaces
• Supports exact-number-of-times and at-least-once verification
• Argument matchers
• Annotation support

Remember that for Mocking, we will use mocks in our object. So, if you are using interfaces and IOC you can write your own fake implementations and inject it in your tested object. However, writing fake implementations for every linked objects could be very fastidious. That's why we will use mock libraries.

Differences between both:

Mockito has a simplified api that results in much flatter learning curve and ease of writing and maintainability. A great benefit outlined above is the developer doesn't need to call out what mocks need to be replayed. This is handled implicitly in Mockito. That compared to Easy Mock, the learning curve is higher and results in confusion several times when new mocks are added/deleted, all the explicit references need to be accordingly handled. EasyMock results in more code than Mockito to test the same functionality.

 

A simplified EasyMock example below :

TestClassA {   void setup(){ //Create mock ClassBeingMocked mock1 = EasyMock.createMock(ClassBeingMocked); }     void testMethod(){ //Setup expectations EasyMock.expect(mock1.getAge()).andReturn(10); //Replay mode EasyMock.replay(mock1); //Test ClassBeingTested source = new ClassBeingTested(); source.calculateAge(mock1); //Assertions assertEquals(50, source.getAverageAge()); //Verification mode EasyMock.verify(mock1); } }

Same example in Mockito

TestClassA {     void setup(){ //Create mock ClassBeingMocked mock1 = Mockito.Mock(ClassBeingMocked); }     void testMethod(){ //Setup expectations Mockito.when(mock1.getAge()).thenReturn(10);   //Test ClassBeingTested source = new ClassBeingTested(); source.calculateAge(mock1);   //Assertions assertEquals(50, source.getAverageAge());   //Verification mode Mockito.verify(source).someInternalMethodCalled(); } }

Using Mockito:

Definition

Mockito is a Java library used to mock objects.

Basically, you can write the following to create a fake implementation of a List :

List mockedList = mock(List.class);

And you can specify the expected behaviour of your mock for your test case :

when(mockedList.get(0)).thenReturn("first");

MockitoJUnitRunner

Mockito comes with a JunitRunner you could enable like that :

@RunWith(MockitoJUnitRunner.class) public class TestDefaultRule {     @InjectMocks     private DefaultRule defaultRule = new DefaultRule();           @Mock     private AirProductManager apManager;           @Mock     private AirProduct airProduct ; ... }

Doing that, Mockito will create all your mocks for every objects annotated with @Mock and inject those mocks in DefaultRule that was annotated with @InjectMocks.

Inject mock without setters

The annotation @InjectMocks is very usefull when your object do not expose setter as for the object DefaultRule :

public class DefaultRule implements MarkupRule { ...     @Autowired     private AirProductManager airProductManager; ...

airProductManager is private and has no setters, so without the annotation @InjectMocks you would have used very tricky method to inject your mock manually.

Initialize value without setters

Sometimes, you could have some objects initialized by @Value annotation and without setters.
Exemple in TneManager :

public class TneManagerImpl implements TneManager {     @Value("${DimoAuthentificationCryptingStrategy.PassKey}")     private String dimoPassKey;     @Value("${EolAuthentificationCryptingStrategy.PassKey}")     private String eolPassKey; ... }

In this situation, you have a solution using ReflectionTestUtils from Spring in your setup method :

@Before public void initialize () {     ReflectionTestUtils.setField(tne, "dimoPassKey", "dimo");     ReflectionTestUtils.setField(tne, "eolPassKey", "eol"); }

Mock static method

Mockito is not able to mock static method by itself. However when using static method you can mix Mockito and PowerMock.

To enable PowerMock you have to use the runner PowerMockRunner.

Example in AirThirdPartyLinkImplMockitoTest :

@RunWith(PowerMockRunner.class) @PrepareForTest({ Lookup.class }) @PowerMockIgnore("org.apache.commons.logging.*") public class AirThirdPartyLinkImplMockitoTest { ...     @Before     public void initialize() throws Exception     {         // As you don't use MockitoRunner, you have to initialize all mocks with the following line         MockitoAnnotations.initMocks(this); ...     // o use PowerMockito to mock the static call of Lookup.getInstance()     // A lot of stuff just to use Carbon...     // -------------------------------------------------------------------     PowerMockito.mockStatic(Lookup.class);         Lookup lookup = mock(Lookup.class);         when(Lookup.getInstance()).thenReturn(lookup);         PNRConstructManager mgr = mock(PNRConstructManager.class, withSettings().extraInterfaces(Component.class));         when(lookup.fetchComponent(PNRConstructManager.DEFAULT_COMPONENT_PATH)).thenReturn((Component)mgr);       }

Explanations :

Enable the runner :

@RunWith(PowerMockRunner.class)

Explicitely tell which object will be mocked

@PrepareForTest({ Lookup.class })

The following line is needed in the setup method. Otherwise every annotations Mock and InjectMock will be ignored as you don't use MockitoJUnitRunner

MockitoAnnotations.initMocks(this);

and the mock of the static method :

PowerMockito.mockStatic(Lookup.class);     Lookup lookup = mock(Lookup.class);     when(Lookup.getInstance()).thenReturn(lookup );