Application Security Or Network Security, Do I Need Both?

Application Security Or Network Security, Do I Need Both?

The short answer – YES.

Take a moment to think about the last ten years in the software and technology industry.  I bet most of us could come up with more than a few instances where data was stolen, sold to the black market or just had your email account hacked into.  So what do we do about it?

When most people talk about security in the technology space, they start talking about IP address restrictions or firewalls, threat monitoring for DDoS attacks, load balancing for traffic spikes, etc.  These are great network related security and reliability discussions, but they don’t get at the heart of some of the breaches organizations have had in recent years. 

There is a nonprofit called OWASP (Open Web Application Security Project) which was founded to improve the security of software.  They published a list of top ten security related issues that create attack vectors for hackers to compromise your software.  Spoiler, OWASP has been around for almost TWENTY YEARS and some of these items are still on the original list.  DevRite takes application security seriously.  Every application we build, each and every one of these items below are taken into account.  We have invested thousands of hours into our base toolset we deliver to each and every client.  Lets talk about the top ten list and what DevRite does to keep your data yours.

A1:2017-Injection

This spec talks about injection attacks, essentially this happens when you take a field on a page from a user such as an email address and directly use that input (without sanitization or validation) and execute it to a database.  This problem is particularly simple to solve.  1) Use parameterized database statements or 2) Use an ORM (Object-Relational Mapping) for database access.  DevRite uses Entity Framework, a Microsoft recommended ORM for SQL Server.

A2:2017-Broken Authentication

This spec is related to session management, and browser cookie or token safety.  An attacker attempting to utilize this flaw would try to steal your session and pretend they are you and thus maintain their anonymity and assume your access level. (Yikes if you’re an Admin!). 

There are a few mitigation techniques for this, and one of the easiest is to make your cookies HTTP only. This means that JavaScript cannot access it, that way only your browser can send the cookie to the server and it can’t be hijacked.  Reading Cookies from JavaScript is one of the main ways this is compromised, HINT: they got JavaScript into your database by using Injection techniques above to get it on your page - Good thing we protected you from this by using an ORM. 

Tokens are little trickier, but best practice here is to never store your tokens in JavaScript, and this includes browser local storage. Local Storage can be accessed directly by JavaScript or even in the console window.  No security access validation whatsoever. It’s best to allow the databases on the server handle your sessions and tokens and let the JavaScript present your UI.  DevRite never stores tokens in the browser, so rest assured, we are safe here too.

A3:2017-Sensative Data Exposure

This attack is related to getting access to data you shouldn’t be able to get to.  Either via direct data access because of encryption or physical access to the data itself.  DevRite stores all information in secure cloud facilities and ALL data is encrypted both in transit (over the wire) and at rest (when the database is not in use).

A4:2017-XML External Entities

XML is an older technology, but basically this is referring to an attacker that can request a file they shouldn’t have by manipulating request objects that are intended to return files – they just ask for one they shouldn’t have.  DevRite doesn’t use XML based requests unless a third-party tool we are integrating with requires it.  This attack doesn't affect your application directly because we don't build the apps using XML based APIs.  Most of the security concerns here are with SAML based SSO, or SOAP API's.  DevRite uses OpenId Connect & OAuth 2.0 to facilitate SSO and our API's are not SOAP based.  If we must integrate with a SAML client to facilitate SSO - we will ensure that the XML parsing library they are using is patched to prevent this attack from taking place.

A4:2017-Broken Access Control  

This one is similar to broken authentication, with a key difference - manipulation of URL's or HTTP types (get, put, post, delete).  Lets assume you have a site that loads company information at https://thebestwebsite.com/company/345, notice the 345.  Imagine this was behind a login and you had to authenticate yourself to see this URL.  If I put 346 at the end of the URL (which is likely a totally different company) and it loads the data - Bingo.  You have now just allowed someone to view someone else’s company information without authorization.  DevRite has developed a toolkit that we integrate into every application at the database layer.  We validate and check to make sure that the person who is requesting it can access it, and should access it before it ever leaves the database.  That means we ensure that if they aren't supposed to even see it, it never goes over the wire either.

A5:2017-Security Misconfiguration

This one is tough and always prone to error since humans are configuration systems.  This spec is here to highlight the importance of updating third party software such as windows or SQL server, because as your providers find bugs, you want to make sure your application gets those latest security patches.  DevRite maintains these for you if you are on our maintenance plan.  If not, we recommend keeping tabs on releases of the tools that are being used in the project.  We provide a comprehensive list upon request for each tool and its version number at the time of delivery should you choose not to have us take care of hosting and maintenance for you.

A6:2017-Cross-site scripting XSS

This can be summed up into a single word. Validation.  This type of attack occurs like the injection one does, someone submits JavaScript or malicious code using a form on your site, and when your page loads again, the browser unknowingly executes it thinking the site itself is asking it to, even though it isn’t.  This is an easy fix, don’t allow JavaScript to be submitted in your forms. DevRite does this everywhere, and in those cases where it may be required (because there is always edge cases) we ensure that proper risk protections and assessments are made with our clients before continuing.   

We also make sure that a Content Security Policy (CSP) is used for every web application we make.

A7:2017-Insecure Deserialization

This is related to web requests when the server attempts to change things into something it can understand, when doing so, malicious code could be executed during this stage.  The best way to handle this is to never use generic types. Log every failed deserialization request. Sanitize and validate the data. Seeing a pattern here?  When we create your custom applications, usually the API's are secured in such a way that we trust the source of the incoming data.  However, this isn't always the case and since there are always exceptions we make sure that the API's we build handle the lowest common identified issue.  Since some API's are public (such as APIs you want to expose to sell as a product), we make sure that we never use generic types for deserialization.  This virtually eliminates this spec and ever other request failure is logged.

A8:2017-Using components with known vulnerabilities

The name implies the issue here, using components that have had issues identified and not keeping them up to date.  DevRite handles this as well while on our Maintenance Plan.  We will always keep your libraries up to date for the lifetime of your time with us.  In addition to the JavaScript components, this includes the underlying framework your application was built on for the server too.  If Microsoft Releases a new version of .NET Core, we go through every application we host and update it too.  In the event that the change is major(such as going from version 5 to 6 vs 5.1 to 5.2), we'll notify you of the required additional time to complete it and our plan to make sure the transition is as smooth as possible.  Best part, this is a standard benefit to any DevRite customer who hosts and has a maintenance plan with us.

A9:2017-Insufficient Logging & Monitoring

This one is related to auditing and threat detection.  When something does happen, most applications don’t have enough monitoring or logging to figure out the attack vector to find out more information and even to identify the attacker themselves.  Worse yet, they don't have any tools to alert them the problem is happening.  DevRite understand the importance of monitoring and logging, and as part of our hosting features we incorporate a baseline application monitoring as part of our default benefit.  

Wrap it up

Lets summarize - what is important here is that DevRite has you protected for all of the top 10 items on the list for application security.  The reality is attacks can and do happen.  Our job is to make sure we build something for you that has Defense in Depth, so if one of these techniques happens to fail, there are other safeguards in place to make sure that data isn't leaked.  Example, if an attacker does happen to gain access because of a newly discovered vulnerability, even if they call an API with improper URL (because they're guessing to get more data) they can't get it, because they still only have access to what the original user has access to.  The only risk is the risk already taken by your organization to allow that particular user access to the data they already own.

Ready to get started on your next big idea?  Let us work with you on how to get your idea off the ground with the best support, security and tools the industry has to offer.