Hello, everyone.
Today, instead of talking about hacking and breaking into systems as we usually do, we're going to
talk about security and specifically how to secure web sites, web applications, mobile applications
and so on.
Obviously, hacks and breaches have a huge negative impact on companies from the loss of customer trust
to financial losses.
Leaked user data, legal issues and the list goes on.
Now, if you go and do a quick Google search on how to secure your website or application, you're going
to get a lot of garbage.
I was actually so disappointed at the clickbait articles that actually did not explain or give any useful
information.
Most of them suggested that you use backups, you strong passwords and make sure you use HTTPS.
But backups don't secure your web site, they simply help you recover.
Also, using ETPs encrypts the communication, but it doesn't really secure the website.
The only one useful tip was use strong passwords.
But most hackers are not going to sit down and try to guess the password like you see in Hollywood movies.
They're going to rely on vulnerabilities and weaknesses within your application, and they will exploit
them to gain access to it, regardless of what password you use.
Even if you have a very, very complex password, even if you're using HTTPS and even if you have backups,
a lot of this is actually irrelevant.
Also, it doesn't really matter where you have the application hosted, whether you use an A.W. or any
other cloud provider, and it doesn't matter how you're deploying this application.
If you're using Kubernetes or if you're using Docker, it doesn't really matter.
It's actually very, very simple.
If you have a vulnerable web application, then hackers are going to use these vulnerabilities or weaknesses
to gain access to this application.
So anyway, enough ranting.
Let's talk about how to actually secure websites and applications.
First of all, before we start talking about it, it is very important to understand that achieving
100 percent security is impossible.
All we are trying to do is to improve the security of our applications and make sure that they are as
secure as possible.
With that being said, the following four approaches will help you improve the security of your applications,
regardless of what kind of applications they are and regardless where they're installed.
Like I said, it doesn't matter if you install them on Amazon or anywhere else on a WIC or anything
else, and it doesn't matter how you're deploying it if you're using Docker and so on.
So the first thing that you should do is make sure that you are writing secure code this way.
Your application is built from the ground up to be secure and to not introduce any bugs or vulnerabilities
that can be exploited by hackers to gain access.
Now, this would be great if you can do it, but the problem is it's easier said than done because the
developers need to be educated and taught the methods that hackers used to exploit systems and gain
access.
And even if you do that, a lot of the time developers rely on third party libraries and the whole application
might be written by someone else.
Therefore, you simply cannot write secure code because you're not actually the writer or the developer
of this application.
Which brings me to the second point.
Review of the code.
This is actually really good, even if you wrote the application yourself, and even if you made sure
that you write secure code, it's a really good idea to get that code reviewed by other developers or
another team.
Just in case the developers wrote the application missed something or overlooked something, then it
will be caught at the review stage.
Also, if you are using the code written by other developers or third party libraries, then again,
a code review will fix this problem because you can review and everything.
And again, this is really, really good because you're actually reviewing every single line and making
sure that nothing is vulnerable or will allow hackers to exploit your application and gain access.
The main disadvantage here is that if you have a large code base, this could be very time consuming
and it could also be very expensive.
The third approach, which is very essential, in my opinion, is getting a pen test done.
In a pen test.
You basically hire a team of ethical hackers to try and hack your application.
These ethical hackers will approach your application the same way that Black Hat hackers do.
They're going to try to gather as much information as possible and discover all the weaknesses and vulnerabilities
and see if they can exploit them to gain access.
At the end, when they're done, they're going to give you a detailed report of everything they found
so you can pass it to your developers and patch any vulnerabilities they discover.
The main advantage of this method is you could test attack surfaces that you cannot test with other
methods, such as your servers that are running your web application and the weakest link, which is
the employees.
So these hackers, the ethical hackers, can even use social engineering and chain it with other simpler
attacks or simpler vulnerabilities that they might find on your system to see if they can use them to
gain access.
The disadvantages here is that it could be a little bit expensive and it's not future proof.
What I mean is if you get your application tested today by a really good ethical hackers and then make
sure you patch every single vulnerability they find, this only means that your web application is secure
today.
It doesn't guarantee that it will remain secure for the next month or next year, because every single
change you make, every feature you push, or every even display bug you fix might introduce other bugs
or security weaknesses that can be then used to hack into your application.
Not only that, but again if you're updating third party software or plugins again, all of that could
introduce vulnerabilities, and a test will not be able to catch that because you're only doing the
Panthers today, and these future changes are not going to be tested.
The fourth approach, which can actually address this issue, is having a bug bounty program.
A bug bounty program is basically an invitation to all ethical hackers around the world to test your
application and submit their findings.
And you would only pay for valid bugs or valid reports.
The main advantage is here, as you have guessed, probably by now, is that you're getting your application
tested by a large number of hackers, so the chances of them finding vulnerabilities is higher.
And it's actually future proof because as long as you have that bug bounty listing live, these hackers
will always continue to test your application and you motivate them with bounties.
So this could be anything from a T-shirt's to actually monetary awards.
To make sure that they're actually going to continue testing your application.
So even if you're pushing new changes, new features or updating stuff, it doesn't really matter because
hackers will continue to test your application hoping to find bugs and get bounties for their findings.
That's why large companies like Facebook and Google use these bug bounty programs, even though they
follow all of the other approaches.
Like I said, they still use this to make sure that their systems are always as secure as possible and
as free of bugs as possible.
The disadvantages here is, first of all, it's hard to guarantee that all attack surfaces are covered.
And second is, a lot of companies don't have the reach that Google and Facebook have, so they can't
really advertise their bug bounties as well as the big companies do.
They can't get a lot of ethical hackers to test their website.
It is challenging for them to make these bug bounty programs and validate the submitted reports.
But this is addressed by the bug bounty platforms that we have these days, such as bug bounty, dotcom
and the other platforms.
Bug Bounty is actually a sister company of that security.
So my opinion might be a little bit biased, but I'm pretty sure that our prices are the most competitive
and we offer the same service.
So anyway, I'm included in everything there.
You have the choice.
You can check out whatever you want, and I'm sorry if I actually confused you with the fall approach.
Is that I just mentioned, but in my opinion, ideally, you would want to follow all of these four
approaches, if you can.
This could be pretty expensive.
That's why a lot of companies don't do that.
And they would compromise and only go with three and four.
So they'll only do a patch test and have a bug bounty program.
And then other companies sometimes compromise even more.
And pick one of the two either do a bug bounty program or do a pen test.
In my opinion, a pen test is not a replacement for a bug bounty program and vice versa.
I would recommend you do the two of them because, like I said, each one of them has its advantages
and disadvantages.
But if you really can't do both, then at least do one of them as the bare minimum.
As a website owner or an app owner, you are responsible for the user data that the users are trusting
you with, and therefore you need to do at least the bare minimum on trying to make sure that their
data is handled safely and is secure.