Hello, everyone. Welcome back. We have expressed as
for how do we secure certain positions across web
and visits of network security. Now,
let's take a look at additional best practices
that can be incorporated in order to strengthen the
security posture. First thing that I
would like to talk about is segregating the authentication and
authorization.
And application. Typically the way of application behaves
is that once a user logs in,
we generate a session ID that is being passport application for
all the actions.
The approach would be to create a nuanced token
that is generated using all
the security requirements, the way we
generate a session ID and that whatever token is
used for all sensitive actions. For example, may
be updating a profile password or
maybe transferring money depending on
the application requirement. If we can segregate the
sensitive actions performed by the user and we
use the oauth token to actually authorize
And see if that is being generated in a timely fashion and
meeting all the access requirements. That
way we can add an additional layer
of security. We have seen a crack such as brute
force or session fixation, which
lack session management reason being,
is that the way the session management was
implemented is from the developer point
of view.
They themselves to the ownership of creating the session
maintaining the session and purging the
session.
It would be a smart way to develop an application using
their own inbuilt session management. For
example, all the big Frameworks such as Java
PHP and dotnet Technologies. They
have their own built-in session Management in
that way. We don't need to worry about how
do we create a session ID if the
secure enough or not? All these Technologies do
for industry standards, for example, the to generate
along.
A string for a session ID that are quite random in
nature at the same time. They also ensure
how the data is being transmitted and
a daring to all the such as management principles.
The next thing that I want to talk about is
the US forces accepted mechanism. All
example, if we do understand that a
session ID has to be passed to
the application, which is consumed by the server is
through a for certain way.
Example, either to the cookie. So,
in that way, if an attacker is trying to inject the
same session ID. So other variations
such as through the URL or any other form
factor, I should not be accepted. So
ask a developer. They need to ensure that how
are they actually in cop between these
sensory information such as such an ID in terms
of consuming Roth indication and authorization.
One of the thing which is quite important on all other
application is that to ensure that we
encourage our users log out. Reason
being is that as long as a session is
active, that's where it creates in value. The
example that we spoke about where
social media applications do require session
to be maintained or longer period of time.
Those scenarios. Most of the users would
actually just terminate the browser and
actually just access application. The next time
and the session will be persisted.
But in case, if the u.s. I encouraged log
out, it would not really matter because
the session would be pushed. We
don't need to take additional precaution that an
additional layer of validation happens on the server side stating
that since the user performed, a
law, Court action, that particular session, ID value no
longer persist.
This is one other common security perspective is
that we should encourage the users to do so.
One of the recent Technologies is HTML5 and
these particular technology actually store
the information.
So there are certain apis that are
capable enough from the HTML technology point
of view which actually store information
in the local storage and
that could be either information leakage or
other applications accessing
the shared system. So we need to ensure
that proper security mechanisms are implemented while
using HTML5.
The next thing would be when shot that is
such an IDs are also treated as user input.
What you mean by that? Is that unlike any user
input that is being fed to the system, either through
of form or to DPI. We do ensure that
all the common web attacks are terminated either
for cross-site scripting or SQL
injection or in is impeccable attack. So,
similarly, you also need to ensure that even
the session ID value also doesn't
contain any invalid character that
can break the application.
Maybe give away to a new one ability.
So just to reiterate,
this is it to sanitize all
the values that are being consumed by the application, starting
from the user input through the
session IDs that can be tampered.
One of the use case you want to talk about is
the complex applications.
For example, in an ecosystem, a person
is trying to perform a single
sign-on and that particular user is also capable
enough to access multiple
applications under the same industry. So
we need to be cognizant
of the fact that while generating individual cookies
for each application. How do
we actually maintain the persistent
for each one of those in terms of
Jan and authentication, for example, the
basics would be to ensure that both the cookies that
are being used, should have a different nomenclature such
that it doesn't happen where
one of the application whose expiry
time was in standard industry format
and the second application being a social media, which
had a long expiry date, but just because
of the fact that both use the safety name and
there were no additional cookie flag.
That was set in terms to
validate who can access then, that
becomes a new thread where that particular key
value is applicable throughout the
multiple browser sessions.
The next thing is something that we already spoke about saying
that if we can segregate the
authorization and authentication out of
the application, we can add an additional layer of
the authentication for
critical actions. This could happen in terms of
a multi-factor or it can happen where
we actually. I was the user to
re-login so that we can validate and
provide one usage and ID.
So while genetic session ID, we can also add additional factors
such as Source IP or username agent
to bind in such a way that
we can uniquely identify from where a person is
logging from. In that way. If
that's a requirement, where we want to avoid multiple
session ID is being generated the other parameter and
of actually always help to
differentiate between simultaneous access.
Results for this video. Thank you.