we all know that attacks are techniques that attackers use to exploit vulnerabilities applications or break to break into the application or to hack into the application and web app attacks were still the most prominent or most frequent scene attacks today because of the sheer attack surface and dc accessibility for It so as applications grow, and complexity so does the attack surface and attack with this. for example, feeding some 10 12 years back where you had to do some banking and you need to transfer some money you would have a website where you would have to register and to transfer the money or you would have to go to the bank. But today you have mobile apps contactless payment options you could pay with your fingerprint you could pay with your face ID you could pay with your selfie MasterCard.
So if you look at the Verizon data breach investigation report that came out recently for 2020, 45 of the attacks are still attacks that happen on the application layer, or what they categorize as application hacking where it would be some extra vulnerabilities within the application that needs to be exploited and eighty percent among those attacks are involved with brute force or loss of laws lost in stolen credentials so let’s look into that statistics a bit more, so 80 of them are stolen credentials being tried into websites what that means is that there would be a drop of credentials that are available from previous attacks that the attackers would download and try it on all the other websites.
So if you were a registered user on that website that was breached and you’re reusing your credentials and chances are that those credentials work and the attackers would be able to get in. so that’s a quick win and quick monetization for the attackers that they easily go after so the remaining would be about exploiting vulnerabilities within the application abusing functionality and all that and the vulnerability is being exploited if you take a deeper look into that there mainly SQL injection is the most prominent one followed by PHP injection cross-site scripting local file injection and all that.
Attack Distribution by Types
SQL injection is still the most prominent one followed by remote file inclusion and cross-site scripting, so these are the attacks that are observed they don’t it doesn’t mean that these were successful. it was about confirmed exploited vulnerabilities so that’s you can see the cross-site scripting is more here because there are lots of bots that attempt cross-site scripting whereas they might not be successful, so the point here is that these attacks like SQL injection, cross-site scripting which has been around for years are still very prominent and very much applicable today.
Identifying Application Attacks
So moving on about identifying the application attacks we could employ several techniques and processes throughout our secure development life cycle to identify the attacks both manual and automated for example right from requirements is you could make it a requirement to have a captcha which would prevent some of the brute force attacks or you could make strong requirements for input validation and output validation which should mitigate some of the attacks like cross-site scripting or and some injection attacks in the design phase we could do threat modeling do security architecture reviews and employee strict coding standards and design patterns review and development phase and during the testing phase, we could do pen testing vulnerability assessment we can even have automated tools run throughout the CI/CD pipeline which would look a code which would do code scans or dynamic scans and even third-party components that needs to be analyzed for vulnerabilities.
In the deployment phase, you could make sure your deployment is secure you could also do a threat model separately for your deployment process, and then once the application goes live you would maintain it monitor the logs to make sure it’s healthy.
so, we’ll focus on two main concepts here which have been more effective in identifying attacks.
1. Threat Modelling
- What could possibly go wrong
- Process for simulating attacks and analysing threats
- Involves envisioning the results of specific attacks on your applications and doing something about them.
- Identifying a set of attacker’s techniques, the application is at risk.
Thinking about what we can go wrong, so we can do something about them.
A process that improves the software by
- Understanding security requirements.
- Assessing Risk
- Identifying threats and security bugs early
- Division mitigations
- Engineer and deliver better products
It mainly goes into asking for questions like:
What are we Building?
where we describe what are we building using architecture diagrams DFDs competency Diagrams that do not estimate as much as possible to describe the system in detail.
Threat Modelling- DFD
How we go about building it well on and what are we building step it mainly involves creating detailed diagrams that are clean crisp and precise for a user to understand and then think about that it may not always be the technical folks or engineers who are going to look at these diagrams it may also be risk management or sometimes leadership or business executives who look at it because when you go to them and say hey this is why you want to fix this vulnerability they would need to understand why and they might have to go through these diagrams as well to understand what’s going on and so make sure it’s as detailed as possible and call out all the test boundaries and the data flows as shown in the diagram.
This is a DFD background for a sample blocking site where you can see the website is hosted in AWS it stores all the data in the database we have clearly marked out the internet responder so the user would access the website and he would get redirected to google signing well after successful authentication google would provide a token and the user would go with that token to log in the website will again go and verify that token with google once that’s verified the user is in and he’ll be able to read and update the blogs but pay attention to all the protocols that are defined and then numbered because we’ll be using this for threat modeling databases so about threat generation.
What can go wrong?
which is where we think like an attacker and brainstorm evil as an attacker you would envision all the attacks you would try on that application or those data first and we would call out each of those threads using one of those methodologies like stride or pasta there are several different methodologies we could choose one based on our business and industry.
Threat Enumeration
STRIDE
STRIDE is an acronym for the types of threat it converts, which are:
- Spoofing– pretending or assuming another user’s identity, Impersonating.
- Tampering– Attacker modify input parameters, components, or code to cause harm.
- Repudiation– Allow attacker to cover tracks, remain stealthy when threats events are not logged or monitored.
- Information disclosure– Allows attackers to see unauthorized information, data is leaked or exposed.
- Denial of Service (DOS0– Services or components are inundated with traffic to prevent legitimate use.
- Privilege escalation– Allows attackers to gain additional privileges to gain greater control over a system.
PASTA
PASTA is an attacker-centric methodology with seven steps:
The steps of a PASTA threat model are:
- Define Business objectives.
- Define the technical scope of assets and components.
- Application decomposition and identify application controls.
- Threat analysis based on threat intelligence
- Vulnerability detection
- Attack enumeration and modelling
- Risk analysis and development of countermeasures
What are we going to do about it?
which is where we think like an attacker and brainstorm evil as an attacker you would envision all the attacks you would try on that application or those data first and we would call out each of those threads using one of those methodologies like stride or pasta there are several different methodologies we could choose one based on our business and industry.
Mitigations
| DFD Locations | Classes | Threat | Mitigations | Notes |
| 1,3,5 | Spoofing | Authentication | HTTPS, Multi-factor authentication | |
| 1,3,5 | Tampering | Integrity | HTTPS, Permissions | |
| 1,9,3 | Repudiation | Non-Repudiation | Secure logging and Auditing | |
| 1,3,6,9,10 | Information Disclosure | Confidentiality | Encryption, permissions | |
| 1,9 | Denial of Services | Availability | WAF, input validation, permissions | |
| 9 | Elevation of Privilege | Authorization | Input validation, and permissions |
Did we do a good enough job?
What are we going to do about it in fact our final step would be about did we do a good job which is more like a sprint rest perspective where you would review the whole model that was done to ensure there was enough coverage should we have enough time to do it how could have it been better what areas took more time and how could those time be minimized in future so that modeling is a time-intensive exercise and you want to minimize the time and make sure everybody that’s engaged just making the best out of it.
Retrospectives
- How could we improve
- What could have saved a lot of time
- Was there enough time
- Was the scope clear
- Did we have the right resources?
- Did we engage the right teams/individuals?
- Penetration Testing
- An ethical hacking exercise assumes the role of a hacker, trying to break into an application.
- Pen testing helps security teams to identify areas for improvement and prioritize threat mitigation strategies.
- Threat model for better pen tests.
Testing and validating anything that can potentially go wrong and determining its risks and impact.
Doing threat model prior helps with:
- Better understanding of the application and data flow.
- Better coverage of scope and value
- Assessing Risk
- Reduce time and shows important areas to focus on.
- Provides an attack tree type of checklist to say on track.
Final Thought
Untyped scripting languages, which are popular among programmers, suffer from a general lack of language-level support, which is a significant source of application-level security vulnerabilities. In the case of these languages, it is the programmer’s responsibility to manually check that all user input has been correctly encoded.
