What is Web Security?

| Purpose of Web security | Web

Security Threats and Approaches | How can achieve web
security | web security threats
Web Security Threats & Approaches

What is Web Security?

Web security refers to networks, computer system and data are protected from
unauthorized person or group.

Purpose of Web Security

The purpose of web security is to prevent security attack like Passive attack and Active
Attack. Web security maintains the smooth operation of any business that uses
computers and prevents hackers and malware from manipulating your systems,
software, or network.

How can achieve Web Security?

Various tools & technologies are available to achieve web security:

Web & Network Firewall: Web Application firewall sets between your website server
and the data Connection. The purpose is to read every bit of data that passes through it
and to protect your site.

Keep your software & plugins up to date: If your website's s/w or applications are
not up-to-date, your site is not secure. Updates are vital to the health and security of
your website. Take all software and plugins update request seriously. Also use https
and SSL Certificate to secure your website

Strong password policy: It is important to use strong passwords to protect against

brute force, password should be complex, containing uppercase and lowercase letters,
numbers and special characters. Your password should be at least 10 characters long.

Password cracking tools: Password cracking tools help restore lost password,
whether you have forgotten a password of your password has been hacked, a password
Cracking tools can help you recover it.

Scan your website for vulnerabilities: It is important to regularly perform web

security scans to check for website and server vulnerabilities. web security scans
should be performed on a schedule and after any change or addition to your web
Components.

Use of Antivirus: Antivirus software helps protect your computer against malwares
and other incoming threats. Antivirus software looks at data - like webpage, files,
software applications – which are travelling over the network to your device. It
searches for known threats and monitors the behaviour of all programs and flagging
suspicious behaviour.

What are Web Security Threats?

Web security threats are vulnerabilities within website and applications or attacks
launched by malicious users. Web security threats are designed to breach security of
website or applications. Web security threats involve malicious people and
 organizations, as well as the tools they use to leverage the internet in an attempt to
infiltrate your network or devices. The most common security threats are malware,
phishing, denial of services, SQL injection, stolen data.

Modification of Message: Message should not be altered during transmission it is also

called as data breach. It means some confidential and sensitive information gets
exposed. It is one kind of threat.

Denial of Services: It is known as DDOS (Distributed Denial of Services). It is a web

security threat that involves attackers flooding servers with large volumes of internet
traffic to disrupt service and take websites offline. The sheer volume of fake traffic
results in the target network or server being overwhelmed, which leaves them
inaccessible.

Phishing: Phishing attack targeting users through email, text message or social media
messaging sites. Attackers impersonate of real user or website, users can trust that link
and click on given link and provide sensitive information like account number,
credit/debit card data and login credentials. User Can lost their money, sensitive
information etc.....

SQL Injection: SQL stands for structured query language. SQL is used to search and
query database. SQL Injection is a website security threats. SQL injection is the
placement of malicious code in SQL statement, via webpage input. Using SQL injection
hacker can retrieve credential and some sensitive information.

Malware: Malware stands for "Malicious Software”. It is a file or code, typically

delivered over a network, that infects, explores, steals or conduct virtually any
behaviour an attacker wants. Malware comes in so many variants, there are number of
methods to infect computer systems.

Web Security Threats

 The web provides the following threats which makes web security a must:
o The Internet is two way. Even unimportant systems like electronic publishing systems, voice
response, or fax-back are vulnerable to attacks on the Web servers over the Internet.
o The Web is increasingly serving as a platform for corporate and product information and as the
platform for business transactions. Reputations can be damaged and money can be lost if the Web
 servers are subverted.
o Although Web browsers, web servers are very easy to use and manage and web content is easy to
develop, the underlying software is extraordinarily complex. This complex software may hide many
potential security flaws and hence is more vulnerable to a variety of security attacks.
o A Web server can be exploited to gain access to data and systems not part of the Web itself but
connected to the server at the local site.
o Casual and untrained users are common clients for Web-based services. Such users are not always
aware of the security risks.
Web Traffic Security Approaches

 Figure illustrates that one way to provide Web security is to use IP security (IPsec).
 The advantage of using IPsec is that it is transparent to end users and applications and provides a
general- purpose solution.
 Furthermore, IPsec includes a filtering capability so that only selected traffic need incur the overhead of
IPsec processing.
 Another relatively general-purpose solution is to implement security just above TCP.
 The foremost example of this approach is the Secure Sockets Layer (SSL) and the follow-on Internet
standard known as Transport Layer Security (TLS).
 At this level, there are two implementation choices.
 For full generality, SSL (or TLS) could be provided as part of the underlying protocol suite and therefore
be transparent to applications.
 Alternatively, SSL can be embedded in specific packages.
 For example, Netscape and Microsoft Explorer browsers come equipped with SSL, and most Web servers
have implemented the protocol.
 Application-specific security services are embedded within the particular application.
 Figure shows examples of this architecture.
 The advantage of this approach is that the service can be tailored to the specific needs of a given
application.

Secure Socket Layer

SSL Architecture
 SSL is designed to make use of TCP to provide a reliable end-to-end secure service.
 SSL is not a single protocol but rather two layers of protocols, as illustrated in Figure below.
 The SSL Record Protocol provides basic security services to various higher layer protocols.
 In particular, the Hypertext Transfer Protocol (HTTP), which provides the transfer service for Web
client/server interaction, can operate on top of SSL.
 Three higher-layer protocols are defined as part of SSL: the Handshake Protocol, The Change Cipher
Spec Protocol, and the Alert Protocol.
 Two important SSL concepts are the SSL session and the SSL connection, which are defined in the
specification as follows.
o Connection: A connection is a transport that provides a suitable type of service. For SSL, such
connections are peer-to-peer relationships. The connections are transient. Every connection is
associated with one session.
o Session: An SSL session is an association between a client and a server.
 There are a number of states associated with each session. Once a session is established, there is a
current operating state for both read and write (i.e., receive and send).
 In addition, during the Handshake Protocol, pending read and write states are created. Upon successful
conclusion of the Handshake Protocol, the pending states become the current states.
 A session state is defined by the following parameters.
o Session identifier: A random byte sequence chosen by the server to identify an active or resumable
session state.
o Peer certificate: An X509.v3 certificate of the peer. It may be null.
o Compression method: The algorithm used to compress data.
o Cipher spec: Specifies the data encryption algorithm (such as null, AES, etc.) and a hash algorithm
(such as MD5 or SHA-1) used for MAC calculation.
o Master secret: 48-byte secret shared between the client and server.
o Is resumable: A flag indicating whether or not the session can be used to initiate new connections.
 A connection state is defined by the following parameters:
o Server and client random: Byte sequences that are chosen by the server and client for each
connection.
o Server write MAC secret: The secret key used in MAC operations on data sent by the server.
o Client write MAC secret: The secret key used in MAC operations on data sent by the client.
o Server write key: The conventional encryption key for data encrypted by the server and decrypted
by the client.
o Client write key: The conventional encryption key for data encrypted by the client and decrypted by
the server.
o Initialization vectors: When a block cipher in CBC mode is used, an initialization vector (IV) is
maintained for each key. This field is initialized by the SSL Handshake Protocol.
o Sequence numbers: Each party maintains separate sequence numbers for transmitted and received
messages for each connection. When a party sends or receives a change cipher spec message, the
appropriate sequence number is set to zero.

SSL Protocol
 SSL protocol is implemented just above the TCP to provide web security.
 SSL is designed to make use of TCP to provide a reliable end-to-end secure service.
 SSL is not a single protocol but two layers of protocols.
 The SSL Record Protocol provides basic security services to various higher layer protocols.
 SSL Protocol stack

 Three higher-layer protocols are defined in SSL:

o The Handshake Protocol
o The Change Cipher Spec Protocol
o The Alert Protocol

SSL Record Protocol

 The SSL Record Protocol provides two services for SSL connections: Confidentiality and Message Integrity.

SSL Record protocol Operation

 The overall operation of Record Protocol is:

o Fragmentation: Each upper-layer message is fragmented into blocks of 214 bytes (16384 bytes) or
less.
o Compression: Compression is optionally applied. Compression must be lossless and may not
increase the content length by more than 1024 bytes.
o Add message authentication code: MAC is calculated over the compressed data by the following
expression.

(optional){MAC = hash(MAC_write_secret || pad_2|| hash(MAC_write_secret

|| pad_1|| seq_num|| SSLCompressed.type||
SSLCompressed.length || SSLCompressed.fragment))
 where

|| = concatenation,

MAC_write_secret = shared secret key,

hash = cryptographic hash algorithm,

pad_1 = the byte 0x36 (0011 0110),

pad_2 = the byte 0x5C (0101 1100),

seq_num = the sequence number for this message

SSLCompressed.type = the higher-level protocol used to process this fragment

SSLCompressed.length = the length of the compressed fragment

SSLCompressed.fragment = the compressed fragment or plain text (if compression is not used) }

o Encryption: The compressed message plus the MAC are encrypted using symmetric encryption.
Algorithms supported are AES, RC4-40, IDEA, RC2, DES, 3DES and Fortezza.
o Add SSL Header: A header is prepared and added to the message. The header consists of the
following fields:
 Content Type (8 bits): The higher-layer protocol used to process the fragment.
 Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.
 Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.
 Compressed Length (16 bits): The length in bytes of the fragment.

SSL Record format

Change Cipher Spec Protocol

 This protocol consists of a single message of a single byte with the value 1.
Change cipher spec protocol
 The purpose of this message is to cause the pending state to be copied into the current state, which
updates the cipher suite to be used on this connection.

Alert Protocol
 The Alert Protocol is used to convey SSL-related alerts to the peer entity.
 Each message in this protocol consists of two bytes:
o The first byte takes the value warning (1) or fatal (2) to convey the severity of the message.
o The second byte contains a code that indicates the specific alert.

Alert protocol

 If the level is fatal, SSL immediately terminates the connection. Other connections on the same session
may continue, but no new connections are established.
 Some of the alerts of fatal types are unexpected_message, bad_record_mac, decompression_failure etc.
 Alerts of level warning include close_notify, no_certificate, bad_certificate etc.

Handshake Protocol
 This protocol allows the server and client to authenticate each other and to negotiate an encryption and
MAC algorithm and cryptographic keys.
 The Handshake Protocol is used before any application data is transmitted.
 A handshake message has the following format:
o Type (1 byte): Indicates one of 10 messages of handshake protocol.
o Length (3 bytes): The length of the message in bytes.
o Content ( bytes): The parameters associated with this message.

Handshake protocol

 The algorithm has four phases.

 Phase 1. Establish Security Capabilities: This phase is used to initiate a logical connection and to
establish the security capabilities that will be associated with it.
o The exchange is initiated by the client, which sends a client_hello message with the following
parameters:
 Version: The highest SSL version understood by the client.
 Random: A client-generated random number which serves as nonce.
 Session ID: A variable-length session identifier. A nonzero value indicates that the client wishes
to update the parameters of an existing session. A zero value indicates that the client wishes to
establish a new connection on a new session.
 CipherSuite: This is a list that contains the cryptographic algorithms (key exchange, encryption
and MAC) supported by the client, in decreasing order of preference.
 Compression Method: This is a list of the compression methods the client supports.
 o After sending the client_hello message, the client waits for the server_hello message, which contains
the same parameters as the client_hello message. The parameters contains the values which client
had sent to the server and the server has chosen to use.
 Phase 2: Server Authentication and Key Exchange: This phase provides authentication of server to the
client.
o The server sends its certificate (one or more) if it needs to be authenticated.
o The server sends a server_key_exchange message which contains the list of secret keys to be used
for the subsequent data.
o The certificate_request message is sent next which includes two parameters: certificate_type and
certificate_authorities.
o The final message in phase 2, and one that is always required, is the server_done message, which is
sent by the server to indicate the end of the server hello and associated messages.
o After sending this message, the server will wait for a client response. This message has no
parameters.
 Phase 3. Client Authentication and Key Exchange: This phase provides client authentication to the server.
o The client verifies the server certificates and checks whether the server_hello parameters are
acceptable.
o If all is satisfactory, the client sends a certificate message if the server has requested a certificate. If
no suitable certificate is available, the client sends a no_certificate alert.
o Next is the client_key_exchange message which has the same parameters as the
server_key_exchange message.
o The client may send a certificate_verify message to provide explicit verification of a client certificate.
The client encrypts all the previous messages and master secret with its private key.
 Phase 4. Finish: This phase completes the setting up of a secure connection.
o The client sends a change_cipher_spec message and copies the pending CipherSpec into the current
CipherSpec.
o The client then immediately sends the finished message.
o The server sends its own change_cipher_spec message, transfers the pending to the current
CipherSpec, and sends its finished message.

 At this point, the handshake is complete and the client and server may begin to exchange application-
layer data.
 Handshake protocol message exchange

Cryptographic Computations

 Two further items are of interest:

o The creation of a shared master secret by means of the key exchange
 The shared master secret is a 48-byte value unique to this session.
 First, a pre_master_secret is exchanged.
 Then, the master_secret is calculated by both parties.
o The generation of cryptographic parameters from the master secret.
 The parameters include a client write MAC secret, a server write MAC secret, a client write key, a
server write key, a client write IV, and a server write IV, which are generated from the master
secret.
 These parameters are generated from the master secret by hashing the master secret into a
sequence of secure bytes of sufficient length for all needed parameters.
Transport Layer Security (TLS)
 TLS is an IETF standardization initiative whose goal is to produce an Internet standard version of SSL.
 TLS is defined as a Proposed Internet Standard in RFC 5246. Which is very similar to SSLv3.
 We highlight the differences.

Version Number
 The one difference is in version values. For the current version of TLS, the major version is 3 and the
minor version is 3.

Message Authentication Code

 There are two differences between the SSLv3 and TLS MAC schemes:
 The actual algorithm and the scope of the MAC calculation.
 TLS makes use of the HMAC algorithm defined in RFC 2104.
 SSLv3 uses the same algorithm, except that the padding bytes are concatenated with the secret key
rather than being XORed with the secret key padded to the block length.
 The level of security should be about the same in both cases.
 For TLS, the MAC calculation encompasses the fields indicated in the following expression:
MAC(MAC_write_secret,seq_num || TLSCompressed.type ||
TLSCompressed.version || TLSCompressed.length ||
TLSCompressed.fragment)
 The MAC calculation covers all of the fields covered by the SSLv3 calculation, plus the field
TLSCompressed.version, which is the version of the protocol being employed.

Pseudorandom Function

 TLS makes use of a pseudorandom function referred to as PRF to expand secrets into blocks of data for
purposes of key generation or validation.
 The objective is to make use of a relatively small shared secret value but to generate longer blocks of
data in a way that is secure from the kinds of attacks made on hash functions and MACs.
 The PRF is based on the data expansion function (Figure) given as
P_hash(secret, seed)= HMAC_hash(secret,A(1) || seed) ||
HMAC_hash(secret, A(2) || seed) || HMAC_hash(secret, A(3) || seed)
||... where A() is defined as
A(0) = seed
A(i) = HMAC_hash(secret,A(i – 1))
 PRF is defined as
PRF(secret, label, seed) = P_hash(S1,label || seed)
 PRF takes as input a secret value, an identifying label, and a seed value and produces an output of
arbitrary length.

Alert Codes
 TLS supports all of the alert codes defined in SSLv3 with the exception of no_certificate.
 A number of additional codes are defined in TLS; of these, the following are always fatal.
o record_overflow
o unknown_ca
o access_denied
o decode_error
o protocol_version
o insufficient_security
o unsupported_extension
o internal_error
o decrypt_error
o The remaining alerts include the following.
o user_canceled
o no_renegotiation

Cipher Suites
 There are several small differences between the cipher suites available under SSLv3 and under TLS:
 Key Exchange: TLS supports all of the key exchange techniques of SSLv3 with the exception of Fortezza.
 Symmetric Encryption Algorithms: TLS includes all of the symmetric encryption algorithms found in
SSLv3, with the exception of Fortezza.

Client Certificate Types

 TLS defines the following certificate types to be requested in a certificate_request message:
rsa_sign, dss_sign, rsa_fixed_dh, and dss_fixed_dh.
 These are all defined in SSLv3. In addition, SSLv3 includes rsa_ephemeral_dh,
dss_ephemeral_dh, and fortezza_kea.
 Ephemeral Diffie-Hellman involves signing the Diffie-Hellman parameters with either RSA or DSS.
 For TLS, the rsa_sign and dss_sign types are used for that function; a separate signing type is
not needed to sign Diffie-Hellman parameters.
 TLS does not include the Fortezza scheme.
certificate_verify and Finished Messages
 In the TLS certificate_verify message, the MD5 and SHA-1 hashes are calculated only over
handshake_messages.
 The hash calculation also included the master secret and pads.
 These extra fields were felt to add no additional security.
 As with the finished message in SSLv3, the finished message in TLS is a hash based on the shared
master_secret, the previous handshake messages, and a label that identifies client or server.

Cryptographic Computations
 The pre_master_secret for TLS is calculated in the same way as in SSLv3.
 As in SSLv3, the master_secret in TLS is calculated as a hash function of the pre_master_secret
and the two hello random numbers.
 The form of the TLS calculation is different from that of SSLv3 and is defined as
master_secret=PRF(pre_master_secret,"master secret",ClientHello.random
||ServerHello.random)
 The algorithm is performed until 48 bytes of pseudorandom output are produced.
 The calculation of the key block material (MAC secret keys, session encryption keys, and IVs) is defined
as key_block = PRF(master_secret,"key expansion", SecurityParameters.
server_random || SecurityParameters.client_random)
 As with SSLv3, the key_block is a function of the master_secret and the client and server
random numbers, but for TLS, the actual algorithm is different.

Padding
 In SSL, the padding added prior to encryption of user data is the minimum amount required so that the
total size of the data to be encrypted is a multiple of the cipher’s block length.
 In TLS, the padding can be any amount that results in a total that is a multiple of the cipher’s block length,
up to a maximum of 255 bytes.
 A variable padding length may be used to frustrate attacks based on an analysis of the lengths of
exchanged messages.

HTTPS
 HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to implement secure communication
between a Web browser and a Web server.
 The HTTPS capability is built into all modern Web browsers. Its use depends on the Web server
supporting HTTPS communication.
 For example, search engines do not support HTTPS.
 The principal difference seen by a user of a Web browser is that URL (uniform resource locator)
addresses begin with https:// rather than http://.
 A normal HTTP connection uses port 80. If HTTPS is specified, port 443 is used, which invokes SSL.
 When HTTPS is used, the following elements of the communication are encrypted:
o URL of the requested document
o Contents of the document
o Contents of browser forms (filled in by browser user)
o Cookies sent from browser to server and from server to browser
o Contents of HTTP header
 There is no fundamental change in using HTTP over either SSL or TLS, and both implementations are
referred to as HTTPS.

Connection Initiation
 The client initiates a connection to the server on the appropriate port and then sends the TLS ClientHello
to begin the TLS handshake.
 When the TLS handshake has finished, the client may then initiate the first HTTP request.
 All HTTP data is to be sent as TLS application data.
 Normal HTTP behavior, including retained connections, should be followed.
 We need to be clear that there are three levels of awareness of a connection in HTTPS.
o At the HTTP level
o At the level of TLS
o At the level of TCP

Connection Closure
 An HTTP client or server can indicate the closing of a connection by including the following line in an
HTTP record: Connection: close.
 This indicates that the connection will be closed after this record is delivered.
 At the TLS level, the proper way to close a connection is for each side to use the TLS alert protocol to
send a close_notify alert.
 TLS implementations must initiate an exchange of closure alerts before closing a connection.
 A TLS implementation may, after sending a closure alert, close the connection without waiting for the peer
to send its closure alert, generating an “incomplete close”.
 Note that an implementation that does this may choose to reuse the session.
 This should only be done when the application knows (typically through detecting HTTP message
boundaries) that it has received all the message data that it cares about.
 HTTP clients also must be able to cope with a situation in which the underlying TCP connection is
terminated without a prior close_notify alert and without a Connection: close indicator.
 Such a situation could be due to a programming error on the server or a communication error that
causes the TCP connection to drop.
 However, the unannounced TCP closure could be evidence of some sort of attack.
 So the HTTPS client should issue some sort of security warning when this occurs.

Secure Shell (SSH)

 Secure Shell (SSH) is a protocol for secure network communications designed to be relatively simple and
inexpensive to implement.
 The initial version, SSH1 was focused on providing a secure remote logon facility to replace TELNET and
other remote logon schemes that provided no security.
 SSH also provides a more general client/server capability and can be used for such network functions as
file transfer and e-mail.
 A new version, SSH2, fixes a number of security flaws in the original scheme.
 SSH client and server applications are widely available for most operating systems.
 It has become the method of choice for remote login and X tunneling and is rapidly becoming one of the
most pervasive applications for encryption technology outside of embedded systems.
 SSH is organized as three protocols that typically run on top of TCP (Figure):
 SSH Transport Layer Protocol: Provides server authentication, data confidentiality, and
data integrity with forward secrecy (i.e., if a key is compromised during one session, the
knowledge does not affect the security of earlier sessions).The transport layer may
optionally provide compression.
 SSH User Authentication Protocol: Authenticates the user to the server.
 SSH Connection Protocol: Multiplexes multiple logical communications channels over a
single, underlying SSH connection.