Many vulnerabilities we encounter stem from the flaws within the operating system or installed applications.
We usually impact these vulnerabilities or find these vulnerabilities using a slew of different tools
or measures.
However, the most important aspect is applying patches or making configuration adjustments within that
software development and the realm of software development, we need to look at quality over quantity.
That means that we're going to actually look at secure coding.
From the onset of our practice.
Many vulnerabilities we encounter stem from the flaws within the operating system or the installed applications.
We need to address these vulnerabilities through patching or making configuration adjustments as needed.
However, when we talk about secure coding, we really need to do it from the onset.
We need our coding to be secure from the planning stage.
If we just start developing code or developing programs willy nilly, starting to go through the process,
and then decide halfway through the project to involve secure coding, it's going to cost us twice as
much money, twice as many resources, and twice as much time coding and secure coding from the onset
with security is the most optimal use of our time and resources.
Throughout our coding process, we need to provide input validation.
This is where we take the coding and we go through, and we ensure that any process that allows the
user to interact with our program provides a specific functionality.
What do I mean by this?
I know I pounded this calculator algorithm or analogy into the ground, but if I have a calculator,
I need it to only accept zero through nine and some very specific special characters.
Once I start allowing it to have a through Z or some special characters that provide some programming
language to it, I've been validated or provided an avenue for attackers.
To get into that program.
I need to ensure that my calculator is only providing or allowing users to input measures that are specific
to that program itself.
Now, not every program is going to be the same.
We're not drawing up or developing 50 million different types of calculators.
However, does it make sense for a user to be able to use a semicolon or specific special characters
that are coherent with scripting inside the input of the field, I would say no.
When we do input validation, we need to ensure that the inputs that we are allowing users to utilize
is specific to the program and what they need to do.
This prevents not only injection attacks, but cross-site scripting, and it provides a little bit of
layer of security.
Finally, we need to provide some upload security.
How are we going to allow users to upload documents?
Some documents that users are allowed to upload have malware embedded within them, their scripts allowed
within those uploads that could be fatal to our system, and provide a little bit of leverage for the
attacker to get inside.
We need to provide double checks.
We need to validate different uploads as they're going through our system to ensure that this dual layered
approach balances the security and the robust defenses within our system as a whole.
Output encoding provides where the user inputs a field within our forums or within the coding itself,
but we rerender it as it's being outputted in.
What do I mean by this?
If you look at the screen right here, you can see where a user inputted a basic HTML format going in
with just the word very.
However, when it's rendered out, it doesn't provide all those command line or scripting languages
that HTML uses by providing a rendered output.
We prevent users from utilizing our website to provide scripting attacks to other users.
This is going to stop cross-site scripting attacks, as well as other injection attacks that are harmful
to our users utilizing our website services.
HTTP operates in a stateless protocol.
This implies that the web server does not retain user information across different requests.
To address this limitation, we utilize cookies and they serve to remind the server of the user's identity.
They facilitate tasks and navigate through the different pages of an online store by remembering that
cookie.
However, that cookie can also be utilized to provide a session ID.
This session ID is often used in relation to the actual user.
As we stated.
However, what if a attacker is able to get a hold of that specific cookie?
They then have the ability to utilize that session ID.
By utilizing a key management system, we can ensure that cookies that are utilized by legitimate users
are not then utilized by attackers.
We set up the cookies within a secure manner with a timestamp associated with it, and we validate or
invalidate that cookie as the session is terminated.
By performing key management within the system, we can stop attackers from replaying attacks across
our servers.
Authentication is the art of ensuring someone is who they say they are.
We use authentication almost in every IT system that we utilize today, whether it's logging into a
server or authenticating someone to gain access to a specific program.
However, authentication needs to be more than just your username and password.
We need to implement different forms, such as multi-factor authentication or two factor authentication.
We need to verify and then revalidate or re-authenticate using a secondary measure.
We can enforce password policies to make sure that the password is not weak.
Weak passwords contribute to a major portion of problems that we see in it today.
There's an entire list of commonly used passwords that we can that attackers utilize to dictionary,
attack, and brute force attack many systems.
By making and enforcing complex password policies, we can ensure that users aren't easily taken advantage
of.
We want to utilize encryption, not just encryption, on the standard format of the storage drives,
but encryption in transit so that when the user transmits their password and username, it's being encrypted
across the entire data in process.
We're going to lock accounts when required.
If we see that a user has attempted to log into the system three times over and it's still bad, we
need to lock that account.
If we see a user that's logging in at 2 a.m. in the morning, and they've never logged in at 2 a.m.
in the morning, and they have no legitimate reason to be logging at 2 a.m., maybe it's time to look
at locking that count as well.
We need to maintain logs.
Maintaining logs provides us an audit trail.
If we utilize logs in an appropriate manner, then those detection controls can outline and define where
we went wrong on our different policies that we put in place to authenticate our users.
All of these make up different forms or aspects of the authentication that we need to utilize within
our software environment.
Data protection involves data at rest and motion or in use.
When we talk about data at rest, we're really referring to when the data is sitting still on a specific
drive, whether it's a hard disk drive or a solid state drive, whether it's on a server or even a laptop.
Recently, we've had a rash of laptops being stolen out of cars.
You have a laptop sitting on your floorboard.
It's covered up with a sweater or jacket.
You don't think anything about it, and then all of a sudden you come back to your car, the window's
been broken out and the laptop is stolen.
If that laptop has sensitive data on it and it's been stolen, a lot of times we just think, oh, they
took it out and they pawned it off, or they're going to use it for their own purposes.
But that's not always the case.
Any data that was stored on that laptop that was sensitive in nature is a major liability for the company.
By encrypting that data, we've provided an extra layer of protection to safeguard the company's data
assets.
Data in transit needs to be secured as well.
Data in transit means that we're moving data from point A to point B, whether it's a client to client
or a server to server, or even a server to client.
With this aspect of it, we need to provide basic encryption algorithms to ensure that the data is not
being utilized by a man in the middle.
Attack That data as it's being encrypted, is going to safeguard our internal assets as well as provide
an extra layer of data protection.
Finally, data in use while we talk about data in use, and we most often refer to that as being unencrypted,
there is new technology out right now with a heuristic approach that it provides the ability to not
only use data, but to write new data and have that data encrypted as soon as it's being put down.
This new measure will not fully recognize within.
Our industry is fast coming to be a new technology that we should see fairly soon.
Parameterized queries are queries that we usually type into a field or a subfield.
We most often associate this with username and passwords, or when we're looking through something,
through Yahoo or Google.
However, internal databases have a search query as well.
However, what if we utilize a parameterized query where we take drop down menus within a drop down
menu?
It's impossible for a user to actually type in this field.
We've avoided that attack mechanism or that attack vector altogether.
This is where parameterized queries provide us a decent landscape while still providing the needed functionality
of a website.