Shanta Lifestyle Website Development Technical Details
Website Security Plan
1. Password Policy
To be able to create a strong password, the following criteria will be taken into account. These criteria
will basically include the following:
●
●
●
●
●
A strong password has to be at least 8 characters long.
It should not contain any of the user’s personal information — specifically, his/her real name,
username or their company name.
It must be very unique from previously used passwords.
It should not contain any word spelled completely.
A strong password has to contain different types of characters, including uppercase letters,
lowercase letters, numbers and characters.
Moreover to ensure a further layer of security two-factor authentication will be implemented for users
logging in to the system. Two-factor authentication combines multiple layers of security, thereby
enhancing the overall security of the system.
In the case of two-factor authentication the user when signing in from an unknown browser will be
prompted by text with an otp that on entering in the verification stage at the website will allow them to
sign in. This ensures that even if their credentials are breached they will be prompted for a confirmation,
thus adding an extra layer of security.
2. SSL Certificate:
We will be integrating TLS 1.3 in the website. TLS 1.3, the latest and unsurprisingly the most advanced
cryptographic protocol till date. TLS 1.3 has been adopted by all leading browsers already.
When it comes to browsing the internet, two things matter above all else. These things are security and
speed. TLS 1.3, with its faster handshake and security advancements, excels at both. It sheds away the
insecure skin of TLS 1.2 and its predecessors and offers a quicker, secure way to communicate in the
precarious world of internet.
Here are some of the ciphers and protocols of its predecessors abandoned by TLS 1.3:
●
●
●
●
DES
3DES
MD5 Algorithm
RSA Key Transport
●
●
●
●
●
SHA-1 Hash Function
RC4 Steam Cipher
CBC Mode Ciphers
Various Diffie-Hellman groups
EXPORT-strength ciphers
Less traveling = More speed
To ensure a TLS-enabled secure connection to take place, a process named ‘TLS handshake’ must take
place between the client and the server. This handshake involves a series of back-and-forth
communication and verification steps between both entities. During these steps, they come to terms of
data transfer and pave the way for encrypted communication. However, it comes with a constraint –
speed.
With TLS 1.3, we’re about to see a radical change in the handshake time. TLS 1.3 introduces 1-RTT
handshake that cuts the handshake time by almost half, whereas the time taken by TLS 1.2 is 0.25 to 0.5
seconds. In areas where even a microsecond can make a world of a difference, this is nothing less than a
boon.
As good as the 1-RTT handshake is, its 0-RTT Resumption is much more well renowned and well spoken.
Yes, a handshake consisting of zero round-trips! If the server and client have come across each other
before, the handshake will be of zero round-trips. 0-RTT Resumption is accomplished by using the stored
information such as session IDs. This takes the handshake time down to the bottom. This way
unprecedented connection speed has been achieved with the introduction of TLS 1.3.
TLS 1.3 supports all modern browsers and devices. It includes the major browsers like:
●
●
●
●
Google Chrome
Firefox
Internet Explorer
Safari
A basic working of TLS 1.3 can be gained from the image below:
Source: https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/
3. Automate website backups and have an offsite website backup
Website backups will be automatically taken during a 15 day time period. These backups will be stored in
a secure offshore location safe from any natural or man-made disasters.
4. Limit User permissions
The wide array of users will be given permissions to access and modify website content and respective
items as per their designations in the company. A core person (admin) will be responsible for assigning,
monitoring and creating user accounts with their respective permissions. The admin will be able to set
the limit of visibility and editability depending on each respective user’s designation and role in the
organisation.
Users logging into the system will only be able to view items/features of the website that they have been
permitted to work upon. In fact they will be unaware that other features even exist within the
application to which they do not have access to.
For example: If user A is assigned the admin role then he/she will be able to create a new user named
User B assigned to a specific role with particular permissions to access website admin panel features.
User B will not be able to make use of or access any of the features that the admin has not given them
access to. Thus limiting their usage of the admin/website panel to the mere permissions that they were
given.
5. Update Plugins
No plugins will be used for the development of the web application as the entire application will be
developed from scratch and not based on any pre-developed template.
6. Anti-Malware software
To avoid any unwanted programs being installed into the application we will be implementing the use of
the ani-malware software Sucuri (https://sucuri.net/malware-detection-scanning/). The application is
able to provides the following features for ensuring the working of a safe and secure web application:
a. Website Malware Scanner - The scanner monitors for signs of website malware and indicators of
compromise with their website scanning tools.
b. SSL Certificate Monitoring - ensures that any changes made to the website’s SSL/TSL certificate
will prompt an emergency notification to the user.
c. SEO Spam Scanner - Will be able to identify and inform regarding spam keywords and link
injections that might hurt the website/brand.
d. Blocklist status - The scanner monitors for security warnings from blocklist authorities.
e. Website uptime monitoring - will automatically inform the concerned authorities regarding
when their website has become inaccessible to visitors.
f.
DNS Monitoring: If any changes are made to the websites DNS settings the scanner will
immediately inform the respective authorities of the web application so that they are able to
take the required action on their parts.
g. Website Server-side scanning - All files on the server will be checked for signs of malware, finding
backdoors, phishing pages, spam, DDoS scripts and more.
7. DDoS Mitigation service
AWS Shield Standard provides protection for all AWS customers from common, most frequently
occurring network and transport layer DDoS attacks that target your web site or application at no
additional charge. Thus, our decision to go with AWS shield for protection against DDoS attacks.
AWS Shield Advanced is a paid service that provides additional protections for internet-facing
applications running on Amazon Elastic Compute (EC2), Elastic Load Balancing (ELB), Amazon CloudFront,
AWS Global Accelerator, and Amazon Route 53. AWS Shield Advanced is available to all customers,
however, to contact the DDoS Response Team customers will need the Enterprise or Business Support
levels of AWS Premium Support. It requires a 1-year subscription commitment and charges a monthly
fee, plus a usage fee based on data transfer out from Amazon CloudFront, Elastic Load Balancing (ELB),
Amazon Elastic Compute (EC2), and AWS Global Accelerator. You will find these costs included in the
budget prepared.
AWS Shield Advanced charges are in addition to the standard fees for Elastic Load Balancing (ELB),
Amazon CloudFront, Amazon Route 53, Amazon Elastic Compute Cloud (EC2), and AWS Global
Accelerator
8. Protection against cross-site scripting (XSS) vulnerabilities
A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to
accept a request as originating from a trusted source.
This is done by escaping the context of the web application; the web application then delivers that data
to its users along with other trusted dynamic content, without validating it. The browser unknowingly
executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in
order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.
Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason,
escaping characters is implemented to prevent this manipulation and is the top method for securing
code against this vulnerability.
Escaping means that the application is coded to mark key characters, and particularly key characters
included in user input, to prevent those characters from being interpreted in a dangerous context. For
example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and
displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious
content is injected into an application that escapes special characters and that malicious content
uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the
browser if they’ve been correctly escaped in the application code and in this way the attempted attack is
diverted.
The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions,
but XSS exploits have been used to expose sensitive information, enable access to privileged services and
functionality and deliver malware.
Types of Attacks:
TYPE
ORIGIN
DESCRIPTION
Stored
Server The malicious code is inserted in the application (usually as a link) by the attacker. The code
is activated every time a user clicks the link.
Reflected Server The attacker delivers a malicious link externally from the vulnerable web site application to
a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the
attack back to the user’s browser.
DOM-bas Client
The attacker forces the user’s browser to render a malicious page. The data in the page
ed
itself delivers the cross-site scripting data.
Mutated
The attacker injects code that appears safe, but is then rewritten and modified by the
browser, while parsing the markup. An example is rebalancing unclosed quotation marks or
even adding quotation marks to unquoted parameters.
There are a few methods by which XSS can be manipulated
Affected environments
The following environments are susceptible to an XSS attack:
●
●
●
Web servers
Application servers
Web application environments
We will protect against XSS vulnerabilities in the following ways:
●
●
●
●
●
●
●
Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated,
filtered or escaped before echoing anything back to the user, such as the values of query
parameters during searches.
Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL
encoded equivalents.
Give users the option to disable client-side scripts.
Redirect invalid requests.
Detect simultaneous logins, including those from two separate IP addresses, and invalidate those
sessions.
Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might
be manipulated for an XSS attack.
Read the documentation for any of the libraries referenced in your code to understand which
elements allow for embedded HTML.
9. Deploy web application firewall
AWS Network Firewall is a managed service that makes it easy to deploy essential network protections
for all types of Amazon Virtual Private Clouds (VPCs). The service can be setup with just a few clicks and
scales automatically with your network traffic, so there is no need to be bothered about deploying and
managing any additional infrastructure in the case of higher network traffic. AWS Network Firewall’s
flexible rules engine lets you define firewall rules that give you fine-grained control over network traffic,
such as blocking outbound Server Message Block (SMB) requests to prevent the spread of malicious
activity. You can also import rules you have already written in common open-source rule formats as well
as enable integrations with managed intelligence feeds sourced by AWS partners. AWS Network Firewall
works together with AWS Firewall Manager so you can build policies based on AWS Network Firewall
rules and then centrally apply those policies across your VPCs and accounts.
AWS Network Firewall includes features that provide protections from common network threats. AWS
Network Firewall’s stateful firewall can incorporate context from traffic flows, like tracking connections
and protocol identification, to enforce policies such as preventing your VPCs from accessing domains
using an unauthorized protocol. AWS Network Firewall’s intrusion prevention system (IPS) provides
active traffic flow inspection so you can identify and block vulnerability exploits using signature-based
detection. AWS Network Firewall also offers web filtering that can stop traffic to known bad URLs and
monitor fully qualified domain names.
10. Protection against SQL injection attacks
SQL injection is, unfortunately, still a persisting problem in Laravel. But validation of user inputs and
parameterized queries can help reduce the risk of SQL injection. The security of your Laravel application
is a continuous process. And we cannot exhaust all the possible vulnerabilities and solutions in a single
post.
Avoiding raw queries is one of the preventive measures that can be taken to prevent SQL injections.
Doing so, they can enjoy some of the security features already built into the framework. However, if raw
queries are used in any instance server-side validation of user inputs will be implemented.
User input validation can help in the case of “DB::statement” method too. In addition, you can use “?” as
a placeholder for user inputs, then supply the actual values as the second parameter of
the “DB::statement” method.
Testing the app for unhandled exceptions before pushing to production allows the prevention of SQL
Injections. There’s also a way to completely turn off this type of error reporting in Laravel. Even though
error reporting will be turned off in production, useful details about application crashes and errors can
still be found and used from the Laravel log files. The in-page error reporting will be turned off from the
.env file and the values for APP_DEBUG will be changed from true to false.
11. Disable Insecure Cipher Suites
TLS 1.3 addresses the disable of insecure cipher suites. Please refer to point number 2.
12. Use Secure Cookies
In order to prevent an attacker from modifying a cookie, Laravel will encrypt it and create a message
authentication code (MAC) of the ciphertext. When a cookie is received a MAC is calculated and
compared with the one provided in the cookie. If the MAC differs then the cookie has been tampered
with and the request is dropped
The MAC does not protect the integrity of the initialisation vector (IV), only the main body of the
ciphertext. Laravel uses Rijndael (essentially AES, but with a block size of 32 bytes instead of 16 bytes) in
cipher-block chaining (CBC) mode. This means that the ability to modify the IV without detection would
allow an attacker to make predictable changes to the first block of plaintext.
The format for Laravel’s “remember me” cookie is simply the user’s ID string. Therefore, it is possible for
a malicious user to take their own session cookie and modify it so that they are able to authenticate as
any other user of the application. Suppose our user ID is “123”.
Submitting the new cookie will authenticate us as the first registered user which is probably an
administrative level user. A similar process can be used to create a cookie for any other user.
The ability to impersonate an arbitrary user is pretty powerful for an attacker, but where you can go from
there is dependant on the functionality provided by the application. Is there some way of exploiting this
situation that to attack all Laravel applications?
Since the MAC is from the result of a call to json_decode() an attacker can provide an integer. This makes
it quite likely that an attacker is able to provide a ‘valid’ MAC for an arbitrary ciphertext.
So, Laravel is using a block cipher in CBC mode and we have the ability to send arbitrary ciphertexts for
decryption. Can we undertake a CBC padding oracle attack? The answer is, under certain circumstances,
“yes”.
A successful padding oracle attack requires the target application to leak the status of the padding of a
decrypted ciphertext. Looking back to the decryption code above there are three possible places that the
padding status could be leaked by the application:
●
●
●
mcryptDecrypt(): No side channel. Single call to mcrypt_decrypt() which doesn’t deal with
padding at all.
stripPadding(): No (practical) side channel. This method does check if padding is invalid, but will
not report any error and just return the input without modification. There is a potential timing
side channel as returning valid padding involves an extra call to substr(), but we will ignore this.
unserialize(): Leaks the length of the input if it’s not a valid PHP serialization and error reporting
is enabled.
So, if PHP error reporting is enabled then the unserialization of the decrypted data will tell us how much
padding has been stripped off. For example, if unserialize() tells us there was an error at “offset X of 22
bytes” then we know that there were 10 bytes of padding.
Since there is a CBC decryption oracle (in the form of a padding oracle) it is possible to use the “CBC-R”
technique presented by Duong and Rizzo to encrypt arbitrary plaintexts.
CBC mode decryption works by XORing the decryption of a ciphertext block with the previous block of
ciphertext. If the attack can control or know both of the inputs into the XOR operation then they can
make the output, i.e. the plaintext block, anything they want. Since this is a chosen ciphertext attack, the
attacker can obviously control the two blocks of ciphertext. The decrypted block of ciphertext can be
recovered by using the decryption oracle. Therefore, the attacker can encrypt arbitrary messages
without knowledge of the secret key.
We are already making use of unserialize() as the basis of our padding oracle. How about we exploit
unserialize() to perform a PHP object injection attack and execute arbitrary code?
Searching Laravel and its dependencies for classes that define a __wakeup() or __destruct() magic
method turns up several options. In my opinion one of the most interesting classes is the BufferHandler
provided by the monologPHP logging framework because it is used by many different projects. A payload
that can leverage the presence of monolog is much more generic than one that requires other, more
project specific classes (at the time of writing, the monolog package has over 2.5 million downloads from
packagist.org). Also, since monolog is likely to be included using Composer (a PHP dependency manager)
it will probably be registered with the PHP class autoloader. This means that monolog doesn’t have be
explicitly included in the target request as PHP will automatically find and load the class definitions as
they are unserialized.
The BufferHandler class wraps another log handling class. When it is destroyed the BufferHandler will
flush its current log buffer by passing off each entry in the buffer to the actual logger that it contains. A
good choice for the child handler is the StreamHandler class which “stores to any stream resource”, such
as a file. So, the plan of attack is to inject a BufferHandler that contains a StreamHandler pointing to a
file in the web root and has a log buffer containing one entry: code for a simple PHP webshell.
13. Ensure forms and user data validation
All forms and user data inputs will be validated against prior set parameters.
14. Remove all unnecessary web server modules & Follow server configuration files best practices
All unnecessary web server modules identified during the course of development will be removed.
The Laravel framework has a few system requirements. We will ensure that your web server has the
following minimum PHP version and extensions:
●
●
●
●
●
●
●
●
●
●
PHP >= 7.3
BCMath PHP Extension
Ctype PHP Extension
Fileinfo PHP Extension
JSON PHP Extension
Mbstring PHP Extension
OpenSSL PHP Extension
PDO PHP Extension
Tokenizer PHP Extension
XML PHP Extension
15. Perform Penetration testing and vulnerability scanning on regular basis
We will be conducting penetration testing on a 15 day basis to ensure that the site is secure. The testing
will not be done on the WAF but instead will be conducted on the application itself, which ensures that
the test can be conducted at a much faster rate.
Some penetration testing solutions have an option to bypass the WAF entirely, setting the host IP
address as the target which gives you a third option. This can be very useful when you might have a load
balancer in play and want to test multiple hosting servers.
Penetration testing will be conducted using sucuri as well for a further detailed view on how it can be
conducted
please
have
a
look
at:
https://blog.sucuri.net/2020/03/pci-compliance-penetration-testing-and-the-sucuri-waf.html
Systems Checklist
1. Operating system: Linux 18.04
2. Web server: apache 2.4.6, PHP 8+
3. Database: MySQL 8+
4. Processor: as per AWS or selected service provider.
5. Website backup: will be done on a regular basis (15 Days) and stored offsite
AWS Services to be implemented
Sl.
AWS Service
Subscription
1.
S3 Standard Storage
Monthly
2.
DT Inbound: All other regions (0TB per month), DT Outbound (15
TB per month)
Monthly
3.
VPN Connection
Monthly
4.
Amazon Route 53
Monthly
5.
Amazon EC2
Monthly
6.
Elastic Load Balancing
Monthly
Number of Application Load Balances x 1
7.
Elastic Load Balancing
Monthly
Number of Network Load Balancers x 1
Processed bytes per NLB for TCP (20 GB per hour)
Average number of new TCP connections (Per second)
8.
Amazon Aurora MySQL Compatible
Development Stack:
1.
Vue JS
2.
PHP 8
3.
Laravel
Monthly