DCF255
DCF255
Lecture 9 | Application Security
Agenda
Top 10 Vulnerabilities and Proactive Action
Typical/Old Insecure SDLC Process: Resulting in Insecure Software
Cost of Software Defects
New Paradigm: Building Security In (New Secure SDLC)
10 Best Practices for Building Secure Software
Application Security Testing Techniques
May require more than one slide
2
OWASP 2017
Top 10 Web Vulnerabilities
And How to Prevent Them
3
C1: Define Security Requirements
C2: Leverage Security Frameworks and Libraries
C3: Secure Database Access
C4: Encode and Escape Data
C5: Validate All Inputs
A1-Injection A2-Broker Authentication A3- Sensitive Data Exposure A4-XML External Entities (XXE) A5-Broken Access Control A6-Security Misconfiguration A7-Cross-Site Script (XSS)
A8-Insecure Deserialization A9-Using Components with Known Vulnerabilities A10-Insufficient Logging and Monitoring
C1: Define Security Requirements
C2: Leverage Security Frameworks and Libraries
C3: Secure Database Access
C4: Encode and Escape Data
C5: Validate All Inputs
C6: Implement Digital Identity
C7: Enforce Access Controls
C8: Protect Data Everywhere
C9: Implement Security Logging and Monitoring
C10: Handle All Errors and Exceptions
OWASP Web Vulnerabilities and Proactive Action
C1:Define security requirements
Security requirements provide needed functionality that software needs to be satisfied and should be derived from industry standards, applicable laws, and a history of past vulnerabilities.
Instead of having a customized approach standard methods should used, so they can be reuse again in future.
C2: Leverage Security Frameworks and Libraries
Secure code libraries and frameworks that have embedded security help software developers guard against security-related design and implementation flaws.
C3: Secure Database Access
Secure access to all data stores, including both relational databases and NoSQL databases.
Secure queries
2. Secure configuration
3. Secure authentication
4. Secure communication
C4: Encode and Escape Data
Encoding and escaping are defensive techniques meant to stop injection attacks. Encoding (commonly called “Output Encoding”) involves translating special characters into some different but equivalent form that is no longer dangerous in the target interpreter. Escaping involves adding a special character before the character/string to avoid it being misinterpreted.
C5: Validate All Inputs
All data that can be entered or influenced by the user must be treated as untrusted. Before being used, including displaying it back to the user, the data must be checked to ensure that it is in the right length (syntactically correct) and in the right format (semantically correct) ( and in that order).
4
C6: Implement Digital Identity
C7: Enforce Access Controls
C8: Protect Data Everywhere
C9: Implement Security Logging and Monitoring
C10: Handle All Errors and Exceptions
A1-Injection A2-Broker Authentication A3- Sensitive Data Exposure A4-XML External Entities (XXE) A5-Broken Access Control A6-Security Misconfiguration A7-Cross-Site Script (XSS)
A8-Insecure Deserialization A9-Using Components with Known Vulnerabilities A10-Insufficient Logging and Monitoring
C1: Define Security Requirements
C2: Leverage Security Frameworks and Libraries
C3: Secure Database Access
C4: Encode and Escape Data
C5: Validate All Inputs
C6: Implement Digital Identity
C7: Enforce Access Controls
C8: Protect Data Everywhere
C9: Implement Security Logging and Monitoring
C10: Handle All Errors and Exceptions
OWASP Web Vulnerabilities and Proactive Action
C6: Implement Digital Identity
Digital Identity is the way to represent the online transaction. Different levels of authentication should be implemented that may include Password, multifactor authentication and cryptographic authentication.
Every time a user needs to make an important action, such transferring money, or changing the shipping address, he/she should be required to re-authenticate. The server should generate a new session token which should never be written to the local machine.
C7: Enforce Access Controls
Access controls refer to the authorization of a user to access a resource. User or system access should be based on the principle of “least privilege” – granting the least amount of access to do the job for the least amount of time. Application design should check each user’s ability to access a resource and the access control policy and the application code should be separated into different layers.
C8: Protect Data Everywhere
It’s critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is ok to place on the public website. Credit card numbers may be classified as private user data which may need to be encrypted while stored or in transit.
C9: Implement Security Logging and Monitoring
Design your application to log all important application events in order audit activity and conduct compliance monitoring. Logging is essential for forensic analysis and intrusion detection and helps ensure that controls are aligned with real world attacks. Like user input, logging input needs to be checked and encoded to prevent “log injection” attacks prior to writing to the log file.
Mobile applications are at particular risk of data leakage because mobile devices are regularly lost or stolen yet contain sensitive data.
As a general rule, only the minimum data required should be stored on the mobile device.
C10: Handle All Errors and Exceptions
Research at the University of Toronto has shown that lack of error handling or minor mistakes in handling errors, can lead to catastrophic consequences in distributed systems. Error handling should be done in a centralized fashion and error messages to the user should not “leak” critical information about how the application works. All exceptions should be logged for forensic analysis.
5
Vulnerabilities Examples
This query can be exploited by modifying the “id” parameter value as follow:
This makes a request to the application to return all records from the account table, other similar and more severe injections can modify the data, and even cause a loss of data.
https://cai.tools.sap/blog/top-10-web-security-vulnerabilities-to-watch-out-for-in-2019/
Broken Authentication
Vulnerabilities Examples
XSS attacks are essentially malicious injections (client-side) that are added to a web page or app through user comments, form submissions, and so on.
Sensitive Data exposure
Typical/Old Insecure SDLC Process
Inconsistently Builds Insecure Software
9
Typical SDLC Process
Typical SDLC Process: Resulting in Insecure Software
The diagram, figure 2, below follows a typical development process at many software vendors today. This is the development process that the OWASP, in the previous section, wants to avoid because it consistently results in insecure software.
After the specifications for the application have been approved by management, Coding begins.
When all of the parts of the application have been coded, the Build phase begins. Here, application is tested to see if it meets the needs of the stake-holders and application specifications as set out by management. Modifications to the application are made in the User QA phase to ensure all user needs and specifications have been met.
Then the application is handed over to external auditors for Security Testing. In a small shop, the developers, who worked on the project, may “change hats” and provide the security testing.
At this stage, numerous bugs and vulnerabilities will be found requiring a re-coding, re-building, and re-auditing of the application. This repetition will increase budget costs, delay final production, cause professional embossment to the developers, and a “loss of face” by management. In some cases, management may decide to release the application “as is” in order to control costs. Insecure software can never be made secure. It is like carrying water in a leaky pail; you patch one hole, the water escapes through another hole
10
Cost of Software Defects
$60 Billion Annually
Due to Bugs Vulnerabilities and Malware
Results in Fewer Programs, Research
Increased taxes and fees to consumers
Cost of Insecure Software
Figure 3: Cost of Software Defects in US Economy
We often think that software defects are only an inconvenience to the user, but there are real costs that can affect the economy. The largest purchaser of software in the world is the United States government. From their own calculations, they estimate that software defects (bugs, vulnerabilities and malware) cost approximately $60 Billion annually to the US economy (and it is generally agreed that the cost is higher because some companies may not report intrusions). The cost of software defects includes the cost to create a patch for a bug or vulnerability, the system down time resulting from malware, the cost to reimage infected machines, legal costs for loss of life and the training of users on security procedures. This cost breaks down to $6.8 million per hour and $1,888 per second. This $60 Billion is unproductive loss; spending money on fixing defects and damage from malware is money that is not available for other purposes. Organizations affected by software defects must increase taxes, retail prices and fees to consumers. Software defects all of use directly and result in a lower standard of living.
If don’t think software can kill, research the “Therax-25” machine which was designed and tested in Canada and killed 4 people because of a software error.
Image taken from http://www.codeguru.com/blog/category/programming/the-cost-of-bugs.html
11
A New Paradigm: A Software Development Framework for Building Secure Software
Building Security In
12
Security can never be an “after thought”
In the development process or of management’s responsibility
Software manufactures treated differently than other businesses
Can’t sue for damages due to faulty software. No need to invest capital to build secure software
Users (customers) are more interested in features than security
A New Paradigm: A Software Development Framework for Building Secure Software
Security can never be an afterthought in the development process, or in management’s responsibility.
Unlike, other businesses, building a faulty software product does not result in liability litigation. If you went to MacDonald’s and ate a hamburger that made you sick, or if you bought a car that exploded on impact, you could take the manufacture to court and sue for damages. Software manufacturers are treated differently.
You could lose your entire company database due to faulty software, and the manufacture would not be liable (the exception is if the DVD was faulty; the manufacture would replace it).
Manufactures know their customers, customes want more and new features every 2-3 years rather than secure software.
13
Security is Everybody’s Business – New Paradigm
Software vendors should be sued for faulty software and pay damages to businesses
Developers should form professional association and make security engineering a performance criteria
Management should see building secure software as an investment in building trust
Users should make buying secure software a priority over new features
Security is Everybody’s Business
For secure software to be developed, attitudes must change. Software vendors should be treated like other businesses and be sued for faulty software.
Developers should create a professional association and develop a code of ethics where security engineering is a performance criteria.
Management should see secure software as an investment in building trust with its customers.
Consumers should place secure software ahead of new features when they purchase software.
14
Gary McGraw – CTO of Cigital
Builders must practice security engineering, ensuring that the systems [they] build are defensible and not riddled with holes (especially when it comes to the software).
Operations people must continue to architect reasonable networks, defend them, and keep them up.
Administrators must understand the distributed nature of modern systems and begin to practice the principle of least privilege.
Users must understand that software can be secure so that they can take their business to software providers who share their values. (Witness the rise of Firefox.) Users must also understand that they are the last bastion of defense in any security design and that they need to make tradeoffs for better security.
Executives must understand how early investment in security design and security analysis affects the degree to which users will trust their products.
Security must be built into the SDLC process from the very beginning and tested throughout the process. We must build a “culture” where security is everyone’s job, as Gary McGraw explains:
Builders must practice security engineering, ensuring that the systems [they] build are defensible and not riddled with holes (especially when it comes to the software).
Operations people must continue to architect reasonable networks, defend them, and keep them up.
Administrators must understand the distributed nature of modern systems and begin to practice the principle of least privilege.
Users must understand that software can be secure so that they can take their business to software providers who share their values. (Witness the rise of Firefox.) Users must also understand that they are the last bastion of defense in any security design and that they need to make tradeoffs for better security.
Executives must understand how early investment in security design and security analysis affects the degree to which users will trust their products.
Gary McGraw, “Software Security: Building Security In”, Addison-Wesley, New York,2006,p.38 Gary McGraw is the Chief Technology Office (CT)) of Cigital, the largest software tester in the world.
Diagram modified from Microsoft Software Development Lifecycle at https://www.microsoft.com/en-us/SDL
15
Software Development Framework with Security Build In
New & Secure SDLC Design
16
New Framework for Building Secure Software (New & Secure SDLC Design)
With is new culture, a “framework” for building software has evolved. We have learned from observation and experiment what works and this new approach is outlined below..
Review the slide in general reading the blue arrows – the next section of slides will discuss each arrow one by one.
17
Developer Training
Security Design Best Practices
Threat Modelling and Risk Assessment
Notice the process begins with developers who are trained on building secure applications.
Developers cannot build secure applications, or do proper penetration testing, if they do not understand the tools and methodology of the hacker.
Most developers, today will have received some post-secondary security training; otherwise the company should provide the needed education. In 2002, Microsoft closed its doors for 10 weeks, while all developers received basic security training, on threat modeling and risk assessment and best practices for building applications “secure by design”.
18
Design Application and Security Requirements
Create Bug Board
Conduct Security and Privacy Risk Assessment
The next section on Specifications refers to working with the users of the application to design an application which meets organizational and user goals. Notice that the application’s security requirements are designed at the same time.
During the design stage, developers should also research how the design is affected by governmental regulations and privacy considerations.
This is also a good time to develop a “bug board”. This a white board, centrally located, where all “bugs” that are identified in the coding are written down, the date, who identified it, who replicated it, and the date the bug was corrected.
19
Build Design Requirements
Perform Attack Surface Analysis
Use Threat Modelling and Abuse Cases
The design phase is the coding phase, where the coding is done to meet the requirements.
Unlike the previous diagram, which allowed the entire code base to be built, prior to security testing, the security testing is done concurrently as the code is built.
After a design requirement has been met, the code is given to another developer (in a small shop, it could be the same developer) to review the code and attack surface. Hackers will not use the application as you intended, they will try and send information in lengths and formats unexpected by the application. All input must be verified and sanitized before it is used by the application.
And if an application is hacked and fails, it should be designed to fail securely. An important aspect of the testing at this stage is “abuse cases”. These are known hacker exploits that have been researched and identified; as the code is developed it is tested to ensure that it is not vulnerable to the known cases of abuse.
20
Use automated tools
Remove Unsafe Code
Perform Static Analysis (Checkmarx)
The implementation phase begins when the code base has been built into a working application.
At this point, a thorough security review is conducted to best for unsafe functions and removal.
Automated tools are employed because the work is very tedious and prone to human errors.
Static analysis refers to reviewing the code without executing the code. A popular static tool is Checkmarx; it identifies vulnerable lines of code as well as reviewing the code and giving remedial suggestions.
21
Perform Dynamic Testing
Perform Penetration Testing
Perform Testing Review (VeraCode)
In the testing phase, dynamic code analysis is conducted. Dynamic code analysis is when the code is executed on a real or virtual processor.
The application is first checked to see it performs to specifications. Then the code is reviewed for security faults.
The programmer must enter input like a user to test different scenarios: What if the input is not in the length expected, what if the input is not in the format expected, what if the hard drive is full and the input cannot be written to a file. A popular tool is VeraCode which uses the same techniques a hacker uses to find vulnerabilities and design weaknesses.
22
Management Sign Off
Conduct 3rd Party Security Review
Create Incident Report
The first step of the release phase is when management signs off on the project – after the application has been thoroughly tested for performance and security.
Typically, management will also, forward the project to a 3rd party security firm for independent review.
Once the application is released, bugs will be discovered due to specific configuration issues on the client system which the developers could not anticipate. Thus, it is important to create an incident board to log all the issues, to study the root cause of the problem and develop workarounds and patches to fix them.
23
Executive Incidence Response Plan
Monitoring of Attack Surface
Preparation of Patches
Lastly, the development process never ends. While the diagram shows the process as a linear progression, it is more of a loop.
The review phase is about ongoing monitoring of the application and testing of new attack surfaces, as they develop.
As the product matures, patches and upgrades will be tested and developed.
All this work is done under the framework of a policy statement called the Incident Response Plan. The latter codifies the processes, skills, and tools, used to detect, contain, investigate and report cyber incidents that potentially can adversely affect the company’s systems, data, and network.
The plan outlines the procedures for handling security related issues from detection to remediation.
24
10 Best Practices
For Building Secure Mobile Software
25
1. Always assign security to a Champion
Champion is a person who fights for a cause on behalf of someone else
Top Level Manager with authority and access to budgets
Small company could be a security trained developer who over sees security
Large company could be a CISO who is part of the CIO team and responsible for all aspects of security
Always Assign Security to a Champion
A champion is a person who fights for a cause on behalf of someone else. Ideally, this person should be a top-level manager who can argue for appropriate budgets and has the authority to ensure compliance. In a small company, this person could be a security trained developer who over sees the security testing. In a larger company, this could be a CISO (Corporate Information Security Officer) who is part of the CIO team and is responsible for all security related issues. In either case, security is best applied in a top-down fashion and needs a “champion” to get things done, build relationships with stack-holders, get funding, built a security “culture” and awareness of key projects. The champion drives cultural change. The goal is build a culture where security is “every bodies” business. Lastly, the champion should help management understand the risks of non-compliance for network and application security.
26
2. Always model threats during software development
Security requirements are designed with the application requirements
Thinking like the hacker and analyzing possible misuses and compromises your application may cause
Design software to avoid past mistakes
Always Model Threats During Software Development
Security requirements for a project must be developed at the onset of the project when the design specifications are drafted. An application build without considering security cannot be made secure, after its release. History has shown that the organization cost of trying to secure an unsecure application after its release can be 10 times the cost of the original project. Threat modeling involves thinking like a hacker and analyzing the possible misuses and compromises your application may cause. Designing your software to avoid past mistakes is an important step to building secure applications.
27
3. Always use modular code to separate parts of the application
Dividing your code into modules segregates the code
Makes it easier to reuse the code and provides better security
“Sandboxing” technique to isolate dangerous actions to restricted areas.
Separate critical functions of the application and require multiple authentications
Always use Modular Code to Separate Parts of the Application
Object-oriented programming (OOP) is compatible with the modular programming and enables multiple programmers to divide up the work and debug pieces of the program. Dividing your code into modules, submodules and internal APIs creates segregation in your code which isolates parts of the application. For example, your application may have to accept a file from the user. A security technique used by developers is “sandboxing”. The latter isolates the file to an untrusted container within the application and applies the most restrictive policies as to what code runs there. Sometimes this is a restriction on operating system resources and sometimes it’s API hook to redirect calls that are made by the sandbox in order to limit the damage, if malicious code was embedded in the file. Sandboxing is not perfect but does improve security. Modern applications which are built on leveraging the benefits of sandboxing are Google Chrome, Adobe Acrobat 10.1+ Protected View, and MSOffice 2010 Protected View.
Isolating parts also makes the code more reusable resulting in faster development time and fewer lines of code. Similar functions are grouped in the same unit of programming code and separate functions are developed as separate units of code. Each module has its own version number which enables programmers and auditors to more effectively analyze, monitor and fix security design flaws and bugs. If any changes must be applied to a module, only the affected subroutines must be changed, making the program easier to read and understand. Isolation of parts is an important security architecture, similar to “defense in depth”. If one part gets compromised or malfunctions, it cannot affect the other parts of the application. Sounds simple, in practice, complete isolation is difficult to achieve due to authentication an authorization issues. Nevertheless, isolation of parts is a goal to strive making code more reusable, easier to maintain and more secure.
When developing, an application create secure walls between critical functions, especially if the application deals with financial or sensitive data. Between the parts, add layers of authentication requiring the user to login multiple times when executing different functions within the application. Once logged in, the user should only be able to view account status. To change account setting, make a purchase or download account information, the user must authenticate again. The goal is to isolate through authentication to slow down or stop intruders, if they breach the first line of defense, there is another level of defense. This technique will stop most hackers since they are generally very lazy; they will move on to less secure applications.
28
5. Always use tested code libraries
Use only trusted libraries that have been used for many years
Research the library before you use –
Never write your own security code. Use only trusted encryption libraries that have been used for many years
Good libraries have good documentation. Work and test the to employ it correctly
Always use Tested Code Libraries
When buying a new car you are advised by consumer reports to never buy a first year model. The reason is obvious, there may be unidentified problems with the first release. Buying a model that has been manufactured for a number of years, gives you the opportunity to read reports from other owner and for the manufacture to fix the problems. The same is true for code libraries. How old is the library? Does the library have bugs and are they being fixed? Who is working on the library? If the library is open source and you downloaded it from GitHub, use the community to ensure that the project is the right fit for your application and that you have the official version or authorized fork.
A big mistake programmers have made is attempting to write their own security code, resulting in serious security breaches. Specifically, encrypted passwords which need to be stored using well established techniques of hashing and salting. Unless, you are a cryptographic expert (and if you were you would not be in this class) use only tried and true cryptographic libraries. Programmers have made the mistake using the wrong kind of encryption, for example using symmetrical encryption and not salting the password correctly, so that, if the password file is obtained, it can be cracked using a single key. When this happens in large organizations, programmers lose their jobs. Study the different types of security techniques and encryption and learn when to use them correctly. Anyone can claim to have written encryption code, but do you know for sure that the code correctly implements the algorithm? This is not an area where you want to slip. You need to find out who is creating the library and whether the creators are indeed qualified to be doing so. If you can’t find out who the creators are and what their qualifications are, move on to the next one. Only use encryption libraries that have been available for many years. The longevity of the library speaks for itself. Good libraries have good documentation. Read the documentation carefully and make sure you understand it. Look at the sample programs and follow them carefully until you fully understand them. Compile the samples and test them out. Then, write your own test programs until you master the use of the library. Finally, only after you fully understand how to use the library, should you can incorporate it into your product
29
5. Always test application on different mobile platforms and APIs
Good performance and security one platform does not guarantee the same on another
Each platform as different APIs and must be independently tested for performance and security
Research known vulnerabilities and abuse cases and test application on each platform
Goal is to avoid past mistakes
Always Test Application on Different Mobile Platforms and APIs
An application tested and found to good performance and secure on one platform may not it on another. Testing for security means checking to ensure that each platform maintains the confidentiality, integrity and availability of the data. Mobile applications are written for IOS, Android, Windows, and other mobile platforms. Each platform uses programming interfaces (APIs) and must be independently tested for performance and security. Research known vulnerabilities and abuse cases for each platform test to ensure that past mistakes are not repeated. Can a user log in without authorization? Is wireless information in plain text? Lastly, make sure that high privilege changes are properly logged should a breach occur.
30
6. Always add multiple levels of authentication
Consumers like to use static passwords for online transactions.
Main reason for security questions
Passwords with security questions not as good as authentication
Two factor authentication is better
Something I know –password, pin
Something I have – smartphone, dongle
Passwords must be strong. Length more important than complexity
Always Add Multiple Levels of Authentication
As mentioned earlier, human are the weakness link in security and weak passwords are the main reason for network break-ins.
According to studies, consumers generally use static passwords when conducting online transactions while using mobile devices. Hence the use of additional security questions during log in. Using static passwords for authentication has security drawbacks: passwords can be guessed, forgotten, written down and stolen, or eavesdropped and adding a security question don’t offer much resistance. Both methods depend too much on the human element. Therefore, the best course of action is to add additional authentication techniques, such as two factor authentication using email or SMS messaging. Two-factor refers to an authentication system in which users are required to authenticate using at least two different “factors” something you know, password or pin, combined with something they have, smart phone or computer, before being granted access.
Additional authentication shouldn’t result in tolerating weak or reusable passwords. As we saw in the password lab, the best course of action is to use long passwords, with as many different types of characters as possible. This makes the search space to crack the password very large. To make the password easier to remember, password padding can be used. Padding the password with repetition does not make the password weaker, provided the attacker does not see your password. Lastly, always maintain a password history to prevent users from creating a new password and them immediately changing it back to the old password. As a programmer, you must strike the balance between ease of sign up/login with smart security measures which protect privacy and confidentiality.
31
7. Always require minimal data from the user
Design app to request the least amount of data
What information do I need?
Design a “choke point”
Test and sanitize data input for text box, file, variable or library before using the data in the app or storing on the server
Always Require Minimal Data from the User
How much data access is enough? Does your application need permission to view photos/media/files, cameras, microphones, etc? When designing your application, focus on requesting the least amount of data possible from users; this limits the amount of data you must protect. As a programmer, ask yourself what information do you need for the software to function. Once you have made that determination, design your application to hold a signal “chock point”. When you line up for a concert the line may be 10 across, but as you go through the security gates, only one person at time gets through. This is a choke point to make it easier for security to check tickets, whether food concealed or if the person looks nervous or suspicious. In programming, a chock-point has the same purpose. It allows for the checking and sanitizing of input whether from a text box, file, variable or library call. In this way the programmer ensure that the data is in the length and format expected by the application before the data is used or stored.
32
8. Always use automated tools and auditors for testing
Use automated static and dynamic testing tools
Code require too tedious for humans to maintain concentration during entire process
Security testing of the software should also be done by independent 3rd party testing companies
https://www.veracode.com/blog/2013/12/static-testing-vs-dynamic-testing
Another set of eyes independent of the developers who wrote the program is invaluable
Always Use Automated Tools and Auditors for Testing
Application developers should include static and dynamic automated tools to help the code review. Reviewing code is tedious and error prone as human concentration lessens. Automated tools don’t get tired and provide consistent results. These tools attempt to automatically identify security flaws in the code.
Once the app is written, it should be sent to independent penetration testers. Having a “another set of eyes” review the code base is invaluable. The open source community provides an exceptional example of how independent reviewers are far more effective in identifying bugs and issues in software. The investment proves worthwhile in this case. Consider employing an auditor on a consistent basis. Once isn’t sufficient.
See the 10 essential open source security testing tools at https://hackertarget.com/10-open-source-security-tools/
33
9. Always build user trust
Users trust that their authentication information and emails will be stored securely
To buy or use your software program users must trust it
Especially true for apps that use cameras, GPS or microphones.
On web site display privacy policy and explain how data is protected and what will happen if a breach occurs.
Users use number of downloads and user reviews to rate application.
Always Build User Trust
When users give authentication information, or send emails, they are trusting that the information will be communicated and stored in a safe and secure manner. They must trust your application, if they are going to use it. This is especially true with apps that utilize dangerous features like cameras, GPS and microphones. To encourage users to download your app display your privacy policy and what you will do if a data breach occurs. Be clear and specific. Users look for how many downloads an app has had as indicator of trust (i.e. 250,000 downloads). They also look to user reviews of your app and court the “star” rating. (i.e. 4 stars indicates favourable reviews)
34
10. Always stay updated on latest exploits, vulnerabilities
Threat environment constantly changing.
Subscribe to:
www.cert.org
cve.mitre.org
www.owasp.org
After release developers must test app for security threats and vulnerabilities
Prepare and distribute patches
Time Delay in Deploying patches and devices older than 18 months are not supported
Research and Stay Updated on Latest Exploits, Vulnerabilities, and Security Trends
The threat environment is always changing and to a large extent, you will feel that you are playing “catch-up” to the hackers. In order to stay on top of the latest threats and how they may impact your software, you need to maintain regular subscription service. The three most important are:
www.CERT.org
CERT studies vulnerabilities in software products and works with the vendors to solve security problems. It also developes tools and products for organizations to forensic examinations, and analyze vulnerabilities. It also conducts valuable training sessions for improving application and network security.
cve.mitre.org
CVE is now the industry standard for vulnerability and exposure names. CVE Identifiers, names and numbers provide a standardized method for identifying vulnerabilities. CVE Identifiers also provides a baseline for evaluating the coverage of tools and services so that users can determine which tools are most effective and appropriate for their organization’s needs. CVE’s common identifiers make it easier to share data across separate network security databases and tools, and provide a baseline for evaluating the coverage of an organization’s security tools
www.owasp.org
The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. Its mission is to make software security visible, so that individuals and organizations are able to make informed decisions.. OWASP is a community of developers and auditors who provide impartial and practical information about software tools and application security to individuals, corporations, and government. Everyone is free to participate in OWASP and all of its materials are available under a free and open software license
By subscribing to these services, you can stay informed on new vulnerabilities and exploits. The application must be continually reviewed so see how it responds to these new abuse cases. If the application is affected a patch needs to be developed to protect bedfore llThe threat environment is constantly changing so programmers must review new exploits and test them to see if they affect the application.
There can be a time delay of weeks to months before the patch is deployed to affected users. For example, you discover that your application on an Android OS has a vulnerability which you fixed by creating a patch. The latter must be given to the manufacture of the device for its next OS update to the device. Once the manufacturer creates the update, it is forwarded to the teleco carrier to transmit to affected users. However, if the device is older than 18 months, most manufactures will no longer support the device., leaving older devices to increased risk.
There is also the problem of “jailbreaking”; this is the process of unlocking the mobile device to overcome manufacturer restrictions such as the type of software that can be installed, or the teleco network to use. This process increases the risk because it bypasses the built-in security of the manufacturer’s operating system. Jailbreaking invalidates the manufacturer’s warranty so user’s may not receive notice of security updates.
35
Application Security Testing Techniques
SAST, DAST, & IAST
36
Application Security Testing Techniques
Static Application Security Testing (SAST)- used as a Source Code Analysis tool.
White box testing approach that examines the application from the inside, searching its source code for conditions that indicate that a security vulnerability prior to the launch of an application and used to strengthen code.
It is used at a very early in the software development as it does not require a working application and can take place without code being executed.
Dynamic Application Security Testing (DAST)- find security vulnerabilities and weaknesses in a running application
A black-box testing methodology in which an application is tested from the outside typically web apps.
A tester using DAST examines an application when it is running and tries to hack it just like an attacker would.
Some of the methods of security testing by DAST are: fault injection techniques on an app, such as feeding malicious data to the software, to identify common security vulnerabilities, such as SQL injection and cross-site scripting.
DAST can also cast a spotlight in runtime problems like authentication and server configuration issues, as well as flaws visible only when a known user logs in.
37
Application Security Testing Techniques
Interactive Application Security Testing (IAST) -combine the strengths of both SAST and DAST methods as well as providing access to code, HTTP traffic, library information, backend connections and configuration information.
IAST places an agent within an application and performs all its analysis in the app in real-time and anywhere in the development process IDE, continuous integrated environment, QA or even in production
White Box Testing
Black Box testing
Grey Box testing
[2]
[1]
[1]
[1]
Application Security Testing
Testing Roles
Hackers – Access computer system or network without authorization
Crackers – Break into the systems to steal or destroy data
Ethical Hacker – Performs most of the breaking activities, but with permission from the owner
Script Kiddies or packet monkeys – Inexperienced Hackers with little/no programming language skills
Scrip
Security Testing Tool
Metasploit
Veracode
Check marx
W3af
Veracode
CodeScan
39
Summary
The OWASP has conducted a survey of web application vulnerabilities. The most common vulnerability is injection. This can be stopped by creating a choke point and checking and sanitizing all input data
The current procedure for developing software results in insecure software because security testing is at the end of the process and the developers building the code may not have had any security training
A new paradigm is needed with a change in law that makes software vendors liable for faulty software. Developers must form a professional association and see secure coding as a performance criteria. Security must be built into the development process at every step.
Following the 10 best practices for building mobile applications will eliminate all of the 10 Top OWASP vulnerabilities, especially subscribing to web sites which deal with new threats and vulnerabilities. Unfortunately, patches for mobile devices take a long time to be deployed and if the device is old the manufacture may not support the update.
References
[1] Khan. M.E, Khan.F ,” A Comparative Study of White Box, Black Box and Grey Box Testing Techniques”, (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 3, No.6, 2012
[2] https://www.synopsys.com/glossary/what-is-sast.html
[3] https://www.guru99.com/what-is-security-testing.html
/docProps/thumbnail.jpeg