Web security Consideration

 Web Security deals with the security of data over the internet/network or web or while
it is being transferred over the internet.
 Web security is crucial for protecting web applications, websites, and the underlying
servers from malicious attacks and unauthorized access.

What is Web Security?

 Web Security is an online security solution that will restrict access to harmful websites,
stop web-based risks, and manage staff internet usage.
 Web Security is very important nowadays.
 Websites are always prone to security threats/risks.

For example- when we are transferring data between client and server and we have to protect
that data that security of data is our web security.

What is a Security Threat?

 A threat is nothing but a possible event that can damage and harm an information
system.
 A security Threat is defined as a risk that, can potentially harm Computer systems &
organizations.
 Whenever an individual or an organization creates a website, they are vulnerable to
security attacks.
 Security attacks are mainly aimed at stealing altering or destroying a piece of personal
and confidential information, stealing the hard drive space, and illegally accessing
passwords.

So whenever the website we created is vulnerable to security attacks then the attacks are
going to steal your data alter our data destroy our personal information see our confidential
information and also it accessing our password.

Top Web Security Threats

 Cross-site scripting (XSS)
 SQL Injection
 Phishing
 Ransomware
 Code Injection
 Viruses and worms
 Spyware
 Denial of Service
 We need to always update our software.
 Hackers may be aware of vulnerabilities in certain software, which are sometimes
caused by bugs and can be used to damage your computer system and steal personal
data.
 Older versions of software can become a gateway for hackers to enter your network.
 Software makers soon become aware of these vulnerabilities and will fix vulnerable or
exposed areas.
 That’s why It is mandatory to keep your software updated, It plays an important role in
keeping your personal data secure.
Beware of SQL Injection
 SQL Injection is an attempt to manipulate our data or our database by inserting a rough
code into our query.
For e.g. somebody can send a query to our website and this query can be a rough code while
it gets executed it can be used to manipulate our database such as change tables, modify or
delete data or it can retrieve important information also so, one should be aware of the SQL
injection attack.
Cross-Site Scripting (XSS)
 XSS allows the attackers to insert client-side script into web pages.
 E.g. Submission of forms.
 It is a term used to describe a class of attacks that allow an attacker to inject client-side
scripts into other users’ browsers through a website.
 As the injected code enters the browser from the site, the code is reliable and can do
things like sending the user’s site authorization cookie to the attacker.
Error Messages
 We need to be very careful about error messages which are generated to give the
information to the users while users access the website and some error messages are
generated due to one or another reason and we should be very careful while providing
the information to the users.
For e.g. login attempt – If the user fails to login the error message should not let the user
know which field is incorrect: Username or Password.
Data Validation
 Data validation is the proper testing of any input supplied by the user or application.
 It prevents improperly created data from entering the information system.
 Validation of data should be performed on both server-side and client-side.
 If we perform data validation on both sides that will give us the authentication.
 Data validation should occur when data is received from an outside party, especially if
the data is from untrusted sources.
Password
 Password provides the first line of defense against unauthorized access to our device
and personal information.
 It is necessary to use a strong password.
 Hackers in many cases use complex software that uses brute force to crack passwords.
 Passwords must be complex to protect against brute force.

It is good to enforce password requirements such as a minimum of eight characters long must
including uppercase letters, lowercase letters, special characters, and numerals.

 Today when more and more companies and organizations are going digital, the security
of data and authorization to important systems and services is crucial.
 User authentication is central to this security paradigm as it refers to the mechanism by
which the identity of a user is first confirmed before being granted access to a resource.

What is User Authentication?

  User authentication is the process of establishing the identity of an individual who
wants to have access to a particular system or service.
 It involves a process of ensuring that the user claiming to be a specific personality is
substantial through proving credentials like passwords, biometric data, security tokens,
or other authenticity factors.
 This verification step is essential in safeguarding systems and systems’ components
from access and use by unauthorized individuals and entities and in preventing misuse
of information that is considered confidential or sensitive.
Presentation of Credentials: It may be in the form of a user ID and password, a fingerprint,
or other such scans, a token that the user presents, or any other form of authentication factor
that the user presents.
Transmission to the Authenticating System: It forwards the materials to the authenticating
system for verification and authorization based on the included information in the document.
Verification: It checks that the provided information is sufficient for the type of access by
verifying it with the stored entries.
Granting Access: If the identification details provided are tied up with that in the records and
the system has succeeded in authenticating the user, access can be granted to the system or the
service.
Access Denied: If many of the details of the credentials given do not match the details of the
database provided, or there is evidence of phishing or hijacking, access can be denied, and
further security issues could arise, such as alerting the user or system administrator or even
authenticating the credentials further.
Types:
 Password-based Authentication
 Biometric Authentication
 Two Factor Authentication (2FA)
 Multi-factor Authentication (MFA)
 Single Sign-On (SSO)
 Token-based Authentication
Password based Authentication
User authentication types include password-based authentication, whereby people use a unique
code to be allowed entry and use a given system or service.
 It is an easy-to-implement and commonly used technique, though it may be exposed to
password theft or guessing attacks.
 These practices would include proper password management, such as adopting and
implementing strict password management policies, besides practicing techniques such
as salting and hashing of passwords.
Biometric Authentication
 The technique used for validation is a print of a finger, face recognition, or an iris scan,
where it is the biometric structure of a user that is identified.
 Biometric data cannot be easily duplicated, and for that reason, its existence guarantees
high security.
 But the flipside is privacy issues, the other instances include the false negatives and
false positives being a bit questionable.
Two factor Authentication
 This relies on something in the user's possession, such as the password, and also something
the user has at a particular period, such as a smartphone or a token.
 Generally, the security level is too high because if an intruder has access to one of the
used factors, the data won't be available.
 After all, it is impossible to access something we don't have.
MFA
Unlike MFA, there is followed by '2FA' and is presupposed from the need to input two or
more independent values that can be something they know, possess, or are, namely
biometric data.
 It takes this idea further to enhance security even further, but there can be downsides
both in terms of the technical complexity and convenience for an end user.
SSO
 SSO is needed when a user needs to get into many related or integrated systems or
services but using the same username and password.
 Before, the user had to remember a handful of passwords to log in to his accounts on
websites, now, this is only reduced to memorizing just a single password.
 The convenience can only be equaled by a security flaw of centralizing control, this
may quickly become a headache if the credentials were to fall into the wrong hands.
 Now, all other systems that use similar credentials stand compromised
Token based Authentication
 A unique token is created for the users.
 To continue using the system, the users must hold on to this token.
 There are two types of tokens: physical tokens, such as the USB token, and logical
tokens, which are entirely software-based.
 This is a more secure form than the old-style one, although, of course, links are activated
with a password rather than through a token, which is really hard to break or easily
duplicated.
 This, though, might pose an operational issue concerning the process of control and
distribution of tokens.
Cookies
 Cookie is just the textual information about some website.
 When we visit a particular website, some information is saved in your local system so
that when you visit the same website again, this website is able to recognize you and
show you the results according to your preferences. Cookies have been long used in the
internet history and have developed in a magnificent way.

 When you visit a website you actually requests the web page from the server. For a
server, every request is a unique request. So if you visit hundred times, the server will
consider each and every request unique. Since the intensity of requests that arrive at a
server is high, it is obvious and logical not to store every user’s information to the
server. Maybe you never visit again and the same information will be redundant. So, to
uniquely remember you, the server sends the cookies along with the response which is
saved in your local machine. Now the next time you hit the same server, you will get a
response according to you as the server will recognize you.
SSL
Secure Socket Layer is a public key cryptosystem, which is used over application layer to
provide encryption to the data passing over HTTP. SSL breaks the incoming data into fixed
size blocks, fragments them, compresses them, encrypts and adds a MAC header and passes it
to the receiving end. It has four protocols.

 Handshake protocol- Used for establishing a connection.

 Cipher-spec protocol- To notify the handshake is over.
 Record–protocol– Carries actual data.
 Alert protocol– Used for any notification.

Cryptography attacks:
 Chosen plaintext attack
 Chosen cipher text attack
 Known plaintext attack
 Meet in the Middle attack
 Rubber hose attack
 Timing Attack
Privacy on the web

People use websites for several important tasks such as banking, shopping, entertainment, and
paying their taxes. In doing so, they are required to share personal information with those sites.
Users place a certain level of trust in the sites they share their data with. If that information fell
into the wrong hands, it could be used to exploit users, for example by profiling them, targeting
them with unwanted ads, or even stealing their identity or money.

Modern browsers already have a wealth of features to protect users' privacy on the web, but
that's not enough. To create a trustworthy and privacy-respecting experience, developers need
to educate their site users in good practices (and enforce them). Developers should also create
sites that collect as little data from users as possible, use the data responsibly, and transport and
store it securely.

Defining privacy terms and concepts

It is hard to talk about privacy without also talking about security — they are closely related,
and you can't really create privacy-respecting websites without good security. Therefore, we
shall define both.

 Privacy refers to the act of giving users the right to control how their data is collected,
stored, and used, and not using it irresponsibly. For example, you should clearly
communicate to your users what data you are collecting, who it will be shared with, and
how it will be used. Users must be given a chance to consent to your terms of data
usage, have access to all of their data that you are storing, and delete it if they no longer
wish you to have it. You must also comply with your own terms: nothing erodes user
trust like having their data used and shared in ways they never consented to. And this
isn't just ethically wrong; it could be against the law. Many parts of the world now have
legislation that protects consumer privacy rights (for example the EU's GDPR).
 Security is the act of keeping private data and systems protected against unauthorized
access. This includes both company (internal) data, and user and partner (external) data.
 It is no use having a robust privacy policy that makes your users trust you if your
security is weak and malicious parties can steal their data anyway.

Personal and private information

Personal information is any information that describes a user. Examples include:

 Postal address, email address, phone number, or other contact information

 Passport number, bank account, credit card, social security number, or other official
identifiers
 Physical attributes such as height, gender expression, weight, hair color, or age
 Health information such as medical history, allergies, or ongoing conditions
 Usernames, when they can be linked to an individual
 Hobbies, interests, or other personal preferences
 Biometric data such as fingerprints or facial recognition data

Private information is any information that users do not want shared publicly and must be
kept private (i.e., information that is accessible only by a certain group of authorized users).
Some private data is private by law (for example medical data), and some is private more by
personal preference.

Personally identifiable information

Following on from the above section, personally identifiable information (PII) is information
that can be used, in whole or in part, to track down and/or identify a specific person. For
example, if a site leaks a list of users' names and zip codes online, a bad actor could almost
certainly use this information to find their full addresses. Even if a full-scale leak does not
happen, it is still possible to identify users through less obvious means, such as the browsers
they are using, the devices they are using, specific fonts they have installed, and so on.

HTTPS by default

Transport Layer Security (TLS) provides security and privacy by encrypting data during
transport over the network and is the technology behind the HTTPS protocol. TLS is good for
privacy because it stops third parties from being able to intercept transmitted data and use it
maliciously, for example for tracking.

All browsers are moving towards requiring HTTPS by default; this is practically the case
already because you can't do much on the web without this protocol.

Certificate Transparency

An open standard for monitoring and auditing certificates, creating a database of public
logs that can be used to help identify incorrect or malicious certificates.

HTTP Strict Transport Security (HSTS)

HSTS is used by servers to let them protect themselves from protocol downgrade and
cookie hijack attacks by letting sites tell clients that they can only use HTTPS to
communicate with the server.

HTTP/2
 While HTTP/2 technically does not have to use encryption, most browser developers
support it only when used with HTTPS; so in that regard, it can be thought of as a
feature to enhance security/privacy.

Anti-tracking technology

Browsers have implemented several anti-tracking features that automatically enhance their
users' privacy protection. Many of these block or limit the ability of third-party sites embedded
in <iframe>s to access cookies set on the top-level domain, run tracking scripts, etc.

 The Set-Cookie header SameSite attribute's default value has been updated to Lax, to
provide better protection against tracking and CSRF attacks.
 Browsers have all started to block third-party cookies by default.
 Browsers are implementing technologies to allow third-party cookies only in certain
circumstances that do not damage privacy, or to implement common use cases that
currently require third-party cookies in alternative ways.
 Several browsers strip out known tracking parameters from URLs — this includes
Firefox, Safari, and Brave. Browser extensions also help to do this, for
example ClearURLs.
 Browsers have implemented redirect tracking protection.

Privacy considerations for client-side developers

There are several actions web developers can and should take to improve privacy for their
users.

Collect data ethically

Companies collect lots of different data from their users for a variety of different reasons:

 Usernames, passwords, emails, etc. for authentication purposes.

 Emails, postal addresses, and phone numbers for communication.
 Age, gender, geographical location, favourite pastimes, and a host of other PII for
anything from site personalization to customer satisfaction surveys.
 Browsing habits on their sites and other sites, to measure page and feature success
metrics.
 And so much more.

When collecting data from our customers, we have an opportunity to behave with integrity,
show them that we are trustworthy, and build a great relationship with them, in turn, improving
our brand and our chance of success.

The ethics of data collection can be broken down into three simple principles:

 Don't collect more data than you need

 Communicate clearly how you are going to use the data you collect
 Delete the data once you have finished with it

Don't collect more data than you need

It is tempting to ask for a lot of data from your users because you think it might be useful in
the future. However, every bit of extra data you collect adds risk to your users' privacy and
increases the chance that they will abandon the step they are performing (whether it is filling
out a survey or signing up for a service).

It is good to anonymize data. We should also consider whether we can get what we need by
making our data request less granular. As an example, instead of asking a user their favourite
products, we could ask them to select between more general categories.

The best way to protect user privacy though, is to minimize the data we collect. Referring to
the previous example, we could infer the same data by looking at user purchase history. As
another example, users appreciate being able to buy products anonymously. We shouldn't force
them to sign up for an account; if it's not necessary for the service to operate, it should be their
choice.

Communicate clearly how you are going to use the data you collect

Once we have decided what data we are going to collect, we should publish a privacy policy
on our site that clearly states:

 Data that you collect

 Ways in which you use the data
 Parties with whom you tend to share the data, if at all, and a declaration that you will
ask for user consent before sharing
 The duration for which you keep the data before it is deleted
 Ways in which users can view the data you have collected from them and delete it if
they want to

When providing you with data, users should be given an opportunity to read our privacy policy,
and consent to it. They should be able to control if they are happy with this and agree to your
terms. And as indicated above, they should also get to see what data of theirs we have collected,
and delete it if they want to.

When you've published your privacy policy, you need to make sure that you comply with it —
doing what you say you are going to do is very important in building user trust. You should
only collect the data you say you'll collect, and only use it for the purpose you say you'll use it
for. If someone from your company comes up with a clever new way to use existing data, that
still isn't OK under the terms of your policy if it doesn't specify that you'll use it for that purpose.
If users consented to the use of their data for a specific purpose and that purpose expands, you
may have to consider obtaining new consent.

Delete the data once you have finished with it

Earlier on, we mentioned giving users a way to see what data of theirs you have collected, and
delete it if they want to. You could possibly do this as part of the same experience they can use
to delete their account (their data goes with it), or make them two separate options. Either way,
the options should be easy to find.

Allowing the user to choose when significant portions of data get deleted is very empowering,
and builds trust, but there may be some bits of data that you will want to handle deletion of
yourself. For example, some data might only be used for a few hours or minutes and then
deleted, like data that is used during the administration of a user's session while they are logged
in.

+
Carefully manage third-party resources

Of course, it would be easy to manage privacy if you were only worried about resources you
have created (code, cookies, sites, etc.). The real challenge comes from the fact that your site
will likely use third-party resources. This can include third-party content embedded
in <iframe>s, libraries, frameworks, APIs, externally-hosted resources such as images and
videos, etc.

Third-party resources are an essential part of modern web development; they provide a lot of
power. However, any third-party resource you allow onto your site potentially has the same
permissions as your own resources; it all depends on how it is included on your site:

 JavaScript running inside third-party content embedded in your site via an <iframe> is
separated by same-origin policy, meaning that it wouldn't have access to other scripts
and data included in the top-level browsing context.
 However, a third-party script included directly in your page via
a <script> element would have access to your other scripts and data, whether it was
hosted on your site or another site. It would effectively be first-party code. A malicious
script included in this way could secretly steal your users' data, for example sending it
off to a third-party server.

It is important to audit all of the third-party resources you use on your site. Make sure you
know what data they collect, what requests they make and to whom, and what their privacy
policies are. Your carefully designed privacy policy is useless if you use a third-party script
that violates it.

Note: There are various tools out there that can help you build up a picture of what requests a
site is making, for example the Request Map Generator.

Once you have audited your third-party resources and understand what they are doing, you
should then consider their negatives as a trade-off for the value they bring. If a third-party script
is free and really useful but collects quite a lot of user data, you could:

1. Accept that trade-off, update your privacy policy to include details of it, and hope that
it doesn't impact your users' trust too much.
2. Look for an alternative, less data-hungry third-party tool.
3. Build your own tool.

The following list provides some tips on how to mitigate privacy risks inherent with using
third-party resources:

 When embedding third-party resources, consider if there is a way to achieve the same
or a similar effect with less privacy impact. For example, it might be fun to have a social
media post viewer embedded on your site, but is it really necessary? Wouldn't a link to
your social media page be sufficient? Also, some third-party services have privacy-
enhancing options. See, for example, YouTube's Embed videos & playlists > Turn on
privacy-enhanced mode.
 Where possible, you should block third parties from receiving a Referer header when
you make requests to them. This can be done in a pretty granular way, for example by
including rel="noreferrer" on external links. Or, you could set this more globally for
the page or site, for example by using the Referrer-Policy header.
 Use the Permissions-Policy HTTP header to control access to API "powerful
features" (such as notifications, geolocation data, accessing media streams from
 webcams, etc.). This can be useful for privacy because it stops third-party sites from
doing unexpected things with these features, and users don't want to be unnecessarily
bombarded by permission prompts that they may not understand. You can also control
usage of "powerful features" inside third-party sites embedded
inside <iframe> elements by specifying permissions policies inside an allow attribute
on the <iframe> itself.
 Use the <iframe> sandbox attribute to allow or disallow usage of certain features inside
the content embedded in the <iframe> — this includes things like downloads, form
submissions, modals, and scripting.

Protect user data

You need to make sure that user data is transmitted and stored securely once you've collected
it. This is more of a security topic, but it is worth mentioning here — a good privacy policy is
useless if your security is lax and attackers can steal the data from you.

Some guidance on protecting your user's data:

 Security is hard to get right. When implementing a secure solution that involves data
collection — particularly if it is sensitive data such as sign-in credentials — it makes
sense to use a reputable solution from a well-respected provider. For example, any
respectable server-side framework will have built-in features to protect against common
vulnerabilities. You could also consider using a specialized product for your purpose
— for example an identity provider solution, or a secure online survey provider.
 If you want to roll out your own solution for collecting user data, make sure you
understand what you are doing. Hire an experienced server-side developer and/or
security engineer to implement the system, and ensure it is tested thoroughly. Use
multifactor authentication (MFA) to provide better protection. Consider using a
dedicated API such as Web Authentication or Federated Credential Management to
streamline the client-side of the app.
 When collecting user sign-up information, enforce strong passwords so your user's
account details cannot be easily guessed. Weak passwords are one of the main causes
of security breaches. Encourage your users to use a password manager to generate and
store complex passwords; this way they won't worry about remembering them, or create
a security risk by writing them down.
 Don't include sensitive data in URLs — if a third party intercepts the URL (for example
via the Referer header), they could steal that information. Use POST requests rather
than GET requests to avoid this.
 Consider using tools like Content Security Policy and Permissions Policy to enforce a
set of feature usage on your site that makes it harder to introduce vulnerabilities. Be
careful when doing this — if you block usage of a feature that a third-party script relies
on to work, you may end up breaking your site's functionality. This is something you
can look into when auditing your third-party resources