Security – HowToCreateApps

“Good does not triumph unless good people rise to the challenge that is around them.”- Alister McGrath As a web developer, you are building the good that the world needs. The good that shakes different industries and creates a better way of life for people. But creating good is not enough, you have to rise up to the challenges that resist such good. For every web application you build, there is someone out there looking to take it down or ruin it all. Someone looking to attack it and carry out their harmful intentions. In this article, you’ll learn about the possible ways these people can use to attack your web applications. When you equip yourself, you’ll have enough knowledge to prevent cyber threats to your web application from attackers. The Web Today The web has evolved since the dot-com bubble, and the world has seen ground-breaking software and technologies. The list is long: Google, Facebook, Amazon, Yahoo, Uber etc. While the average user only sees the web page, you as a web developer know that a lot more is going on in the background that powers those great products. A lot of money is in the software development industry today and a lot of people depend on software usage daily. All of the attention software (web) development is getting, attracting the bad guys. So everyone needs to be watchful. These attackers are looking for different ways to break software and do evil. This urge to break software for whatever reasons they have, drives them. Sadly, there are lots of them out there. While it is the job of a cybersecurity expert to be concerned about the security of applications, you should also be concerned and do as much as you can to make things secure. One things is sure, it won’t be a great feeling if it’s your code that gives the bad guys an inlet to the system. The Effects of Cyber Crime Cybercrime can cause huge damage to everything. From the economy to companies to products and the people. It is therefore surprising to see quite a number of web developers not paying attention to it. Hackers do not only attack web applications to steal money, they also do so to extract secret data, blackmail people and cause uproar in the society. Hence, they can ruin lives and dent company reputation for starters. As you join the battle against cyber criminals, you are creating positive value as a web developer and rising up to the challenge to make the world better. Web Security Fundamentals One of the first things you should understand and accept is that, no code is secure. Except this kind of code. The only way to have code that is one hundred percent secure is to write nothing, and deploy nothing. What this means is that you can only keep reducing vulnerabilities in web applications as you get to find them, but they will always be there. You just need to keep learning about the possible loopholes and patch them, before they are used as exploits. You also need to realise that web application security is a team effort. Attackers have no other task, they think about possible loopholes in their sleep and while they eat. You on the other hand, have a ton of tasks to complete as a web developer. So they have enough time on their hands, to check out as many vulnerabilities as possible. Hackers don’t need many vulnerabilities to cause havoc, they only need one. When they get this one vulnerability, they try to make the most of it. The goal is to gain access to the application’s assets such as local files or source code (if possible), so as to make it act contrary to its purpose. Some web application vulnerabilities are well known in the web application security community, so they are being considered to be “less effective vulnerabilities.” But these vulnerabilities can be very effective, if you as a developer does not know about them. Hence, the effectiveness of a vulnerability is highly dependent on your knowledge of it as a developer. The Threats In this section, you’ll learn about top cybersecurity threats that concern you as a web developer. As you saw in the previous section, some vulnerabilities are quite popular. So the threats in this section will be arranged in decreasing order of popularity and potential damage. The threats you’ll come across here are: Cross-Site Scripting (XSS)Sensitive Data ExposureComponents with Known VulnerabilitiesInsufficient Logging and MonitoringInjectionXML External Entities (XEE)Broken Access ControlBroken Authentication 1. Cross-Site Scripting (XSS) Cross-Site Scripting (XSS) is a popular cybersecurity threat today. According to the Open Web Application Security Project (OWASP) for 2017, two third of web applications have this vulnerability. So it is a common issue and possibly exists in your current web project. You’ll find hackers using XSS to hijack user accounts by stealing user sessions, bypassing Multi-Factor Authentication (MFA). XSS exists in three forms, with each having a different level of possible damage. They are: Reflected XSS: Involves the use of unescaped user input as part of the HTML output. So hackers can use this to execute harmful JavaScript and HTML in the victim’s browser. It is not a very severe attack.Stored XSS: Involves the use of the web application to gather input from the user, this input is then stored for later use. Depending on the type of input being gathered from the user, it can be a very severe attack.DOM XSS: Involves the modification of the Document Object Model (DOM) in the victim’s browser, to make it work in unexpected ways. The hacker can include harmful JavaScript code to exploit the victim. Possible Solution The easiest way to avoid Cross-Site Scripting is to make use of a web framework such as Django or Ruby on Rails. These frameworks have algorithms implemented to prevent XSS attacks. DOM XSS attacks can be prevented by ensuring that context-sensitive encoding is applied when modifying the browser content on the client side. 2. Sensitive Data Exposure Breaking into web applications is not the only way a hacker can gain access to data. You can unknowingly help their cause by exposing sensitive data, so it’s easier for them to access it. You should take data security seriously and make use of strong encryption techniques. It is important that you have sensitive data encrypted at all times, as data can be intercepted when at rest, in transit from the server to the client or available in the client (browser). Attackers do not have to target data directly, they can also target other sources that can give them access. This includes but is not limited to stealing private keys, man-in-the-middle attacks. Possible Solution Always ensure that you use strong encryption techniques, especially for passwords and sensitive data. You can also disable autocomplete on forms that collect sensitive data and disable cache for sensitive pages. 3. Components with Known Vulnerabilities It is common practice for web developers to make use of components or dependencies, instead of writing the algorithms from scratch. This is a good thing, as it helps save time—remember that time is money. But you need to thread this route with caution. Because components may have vulnerabilities and they can be the means of entry for attackers. Stories of web applications that have been exploited due to the use of dependencies having vulnerabilities are common, so it’s important that you update the components often. The older the component, the higher the chances of vulnerabilities being discovered. The worst case is using abandoned components as you’ll be calling the attention of attackers. You should also try to limit the number of components or dependencies being used. This way, you’ll find it easier to track the components that make up the web application. Possible Solutions It is important that you remove all unused dependencies. You should also keep track of the versions of the dependencies being used. Another safety measure is to ensure that all dependencies or components are gotten from the original sources. So you do not have to worry about using components with malicious code in it. 4. Insufficient Logging and Monitoring Successful attacks do not occur overnight. They take time due to planning and vulnerability checks. This implies that there should be signs of an impending attack. But a lot of times, these signs are not seen because logging is insufficient. This makes it easier for attackers to attempt attacks as many times as they want, without being noticed. Since there is little or no logging and monitoring in place, nobody will see the signs until damage has been done. It is not just about creating logs, it is also important that you monitor them and keep them safe. Saving logs on local storage gives attackers the chance to manipulate the logs and keep you unaware of the approaching evil. Possible Solutions Going by the title, the best way to avoid this is to implement proper logging and monitoring systems. Therefore you should log all important information, from failed login attempts to high-value transactions as they are valuable in analyzing possible attacks. The monitoring system in place should raise alerts when suspicious activities are detected. It is impossible to manually monitor activities, so effective automation of the process is needed. 5. Injection SQL injection is one of the most known injection threats to web applications. But injection threats are much more than SQL injection. There are others such as XPath, NoSQL injection threats. The presence of an injection flaw in web applications cause exploits to be successful, so you need to be conscious about this. Injection flaws allow attackers to send harmful code to the web applications; this code can make calls to the server, or database to cause havoc. Injection flaws are easy to detect, as attackers can make use of vulnerability scanning tools to find them out. Hence, you need to be comfortable using vulnerability scanning tools to know what vulnerabilities exist in your web application. Injection exploits can be fatal as they can lead to the corruption of data or the complete loss of it. This can cause the loss of accounts (seen mostly with SQL injection) or even denial of access. Possible Solution You can prevent injection attacks by implementing APIs that avoid the use of the interpreter entirely or making use of the Object Relational Mapping (ORM) tools that come with frameworks. You can also prevent injection attacks by implementing the validation of user-supplied data and escaping special characters found in user inputs. 6. XML External Entities If you build XML (Extensible Markup Language) based web services as a web developer, you’ll need to work with XML processors; so you have to be aware of XEE attacks. Attackers can attack XML processors and cause havoc if they can upload XML, giving them the power to include malicious content in the XML document being uploaded. XEE attacks can be quite severe as they can be used to cause Denial of Service (DOS) issues through XML External Entities. Since many XML processors automatically reduce memory, DOS can be caused by flooding the XML processor with lots of requests. The fatality of an XEE attack can get worse if the attacker can use them to gain access to local files, scan internal systems or execute remote requests from the server. Another contributing factor to the success of XEE attacks is the lack of sufficient logging and monitoring. Possible Solution The best way to prevent XEE attacks is to update all XML processors and libraries in use. This will help reduce the possible vulnerabilities, as they are usually patched when new versions of the processors and libraries are released. You should also disable XML external entity processing in all XML parsers in the application. Check out the XEE Prevention Cheat Sheet for more help in preventing this attack. 7. Broken Authentication Authentication is a common feature in web applications today. Since many web applications require users to have private accounts, authentication systems are needed. Users will usually be able to create accounts, login and change their password when they forget them through authentication systems. Imagine a scenario where a malicious user gains access to the account of another user. Depending on the sensitivity of the information in the account of the user, money can be withdrawn illegally and credentials can be extracted. Authentication systems usually involve the use of a username or a user id and password. But these methods of authentication can be broken if extra measures are not put in place. Extra measures can be restricting the number of wrong user id and password attempts, the use of Two-Factor-Authentication or even cryptographic tokens. As you may agree, the more the users you have on a web application, the greater the chances of high damage when the authentication system is broken. Possible Solution You can prevent broken authentication systems by securely protecting session tokens, so hackers find it difficult to hijack active sessions. Powerful web frameworks have strong authentication systems in place. You can protect authentication credentials and session identifiers with SSL at all times, so user accounts can’t be hacked. 8. Broken Access Control Authentication systems give users access to specific functionality, but access control can break sometimes. It’s a common mistake for web developers to focus only on making the authentication system work, and expecting access control to also work fine too. You shouldn’t make such mistakes. When the authentication system is broken, a malicious user can gain access to the account of another user. But when access control breaks, the user can gain access to pages they are not supposed to have access to, without even logging in. As an example, a regular user on a social media web application should only be able to submit posts or make comments etc. But with broken access control, the regular user can have access to functionality specified for an administrator. It is easy for attackers to find out when an application does not have access control in place through the use of vulnerability scanning tools. In very fatal cases, a user can gain access to any account just by changing the value of the account id in the URL and can do whatever they wish with the account, without having the sign-in details of that account. Possible Solution The most effective solution to prevent broken access control is to deny access to all private resources, pages or functionality by default. But you can make resources that should be accessible by anyone public by default. Successive sign-in failures should also be logged and monitored as that could be a sign that an attacker is trying to break into an account. Resources As a web developer, you do not have to go very deep into cybersecurity as much as a penetration tester would. But a bit of knowledge in the field will make you more valuable and will prove useful. Here are a couple of resources to help you: The Open Web Application Security Project (OWASP) Project: OWASP has a list of web application security risks you need to check out. You’d do well to start off with that. The Damn Vulnerable Web Application: This is a site with a lot of vulnerabilities, you can use it to test your penetration testing skills legally.Web Application Hackers Handbook: Soft Copy | Hard CopyHacker101 (HackerOne): HackerOne is a site for penetration testers. The Hacker101 project will give you a great introduction to web application security.Web Application Security (PluralSight): This web application security course on PluralSight will prove handy for web developers. It’ll help you learn how to develop and maintain secure web applications by applying security principles and techniques. Conclusion It’s great to see that you’ve gotten to the end of this article. You now know about eight common and fatal cyber security threats that web applications can suffer from. You should also have a better view of the importance of security to the web applications you build as a developer. In the resources section, there are carefully picked resources that you’ll find useful as a web developer interested in improving the security of the web applications he builds. Hopefully, you’ve learned a lot from this article, and you share it with other web developers and colleagues at work. Remember that web application security is a team effort.