CSH011 WEB APPLICATION SECURITY

UNIT-IV SECURE WEBSITE DESIGN

Secure website design: Architecture - Design Issues for Web
Applications, Deployment Considerations Input Validation –
Authentication – Authorization - Configuration Management -
Sensitive Data - Session Management – Cryptography -
Parameter Manipulation - Exception Management - Auditing
and Logging - Design Guidelines - Forms and validity -
Technical implementation.
 4.1 Secure website design: Architecture

Presentation Layer: Manages the user interface with HTML,

CSS, and JavaScript frameworks (React, Angular).
Business Logic Layer: Processes data and enforces rules using
backend languages (Python, Java, C#).
Data Access Layer: Handles data storage and retrieval from
databases (SQL, NoSQL).
4.2 Design Issues for Web Applications
4.3 Deployment Considerations Input Validation
1. Assume All Input Is Malicious
Fundamental Principle: Always assume that any input, regardless
of its source, could be harmful. This includes input from external
services, file shares, users, or even databases.
2. Centralize Your Approach
Core Design Element: Make input validation a central part of
your application's architecture. Implementing a centralized
validation strategy ensures consistency across your application and
eases maintenance.
Shared Libraries: Use common validation and filtering logic in
shared libraries. This reduces development effort and ensures that
the same validation rules are applied across the application.
Specific vs. Common Validation: While some fields may need
specific validation (e.g., using custom regular expressions), common
fields like email addresses, names, and postal codes can often use
standardized validation routines.
3. Do Not Rely Solely on Client-Side Validation
Client-Side Validation Limitations: Client-side validation is
important for user experience, but it should never be your sole line
of defense. Since client-side validation can be bypassed, always
validate input on the server side.

4. Be Cautious with Canonicalization Issues

Canonicalization: This refers to the process of converting data
to a standard, canonical form. Be aware that different encodings
and formats can obscure malicious input. Always canonicalize
input before validation to avoid misinterpretation.

5. Constrain, Reject, and Sanitize Input

Constraining Input: Define strict criteria for what constitutes
valid input (e.g., length, type, format) and enforce these rules.
4.4 Authentication
• Separate Public and Restricted Areas: Clearly distinguish
between parts of the application that are publicly accessible
and those that require authentication.
• Implement Account Lockout Policies: Introduce
mechanisms to lock accounts after a certain number of failed
login attempts to prevent brute force attacks.
• Enforce Password Expiration Policies: Require users to
change their passwords periodically to reduce the risk of
long-term use of compromised credentials.
• Manage Accounts Effectively: Ensure that accounts can be
disabled if necessary, such as in cases of suspicious activity
or when a user leaves an organization.
• Avoid Storing Passwords in Plaintext: Prefer using third-party
authentication providers (e.g., OAuth, SAML) or securely store
only hashed passwords if handling authentication internally.
• Require Strong Passwords: Implement policies that enforce
the use of complex passwords to enhance security.
• Encrypt Credentials: Never send passwords or sensitive
information in plaintext; always use encryption to protect data
during transmission.
• Protect Authentication Cookies: Use best practices for cookie
security, such as marking cookies as Secure and HTTPOnly,
and encrypting their contents.
4.5 Authorization
Use Multiple Gatekeepers
Server-Side Gatekeeping:
IP Security Protocol (IPSec): Restricts server-to-server
communication. For instance, you might use IPSec to prevent any
host other than a designated web server from connecting to a
database server.
IIS Web Permissions: Apply to all HTTP resources. While this
helps control access to resources, it doesn't protect against
attackers who manage to log on to the server.
NTFS Permissions: Allow you to set access control lists (ACLs)
at the file system level. Useful for specifying detailed access
controls for users.
ASP.NET Authorization: Combines URL authorization, file
authorization, and principal permission demands to create a
layered security approach.
Restrict User Access to System-Level Resources
System-Level Resources:
Include files, folders, registry keys, Active Directory objects,
database objects, and event logs.
Access Control:
Windows Access Control Lists (ACLs): Control access to
system resources by specifying which users can access what
resources and what actions they can perform.
Anonymous User Accounts: Pay special attention to these
accounts and use ACLs to deny access to sensitive resources.
Example Implementation:
Lock down anonymous internet user accounts with specific ACLs
to prevent unauthorized access to critical system resources.
Consider Authorization Granularity
Authorization Models:
Impersonation Model:
Uses the security context of the caller for resource access.
Works well for intranet-based applications where operating
system-level auditing is needed.
Not suitable for scalable applications due to poor connection
pooling.
Application Process Identity Model:
Uses the application's process identity for resource access.
Supports database connection pooling but results in common
permissions for all users.
Authorization is handled within the application using roles,
with queries restricted by user identity (e.g., UserName =
@originalCallerUserName).
Hybrid Model (Trusted Subsystem):
Combines role-based access in the application with restricted
identities for downstream resources.
Allows effective connection pooling and separate logins for
different roles.
Requires careful management of security contexts and
privileges to avoid violating the principle of least privilege.
4.6 Configuration Management
Configuration management is crucial for maintaining the security
and integrity of web applications.
1. Secure Your Administration Interfaces
Authentication: Use strong authentication methods, such as
multi-factor authentication (MFA) or certificates, to restrict
access to administrative interfaces.
Remote Administration: Limit remote administration to
reduce the risk of exposure. If remote access is necessary, ensure
it's conducted over encrypted channels like SSL/TLS or VPNs.
Restrict access to internal network computers where possible
using IPSec policies.
Local Access: When feasible, require administrators to access
the system locally to mitigate risks associated with remote
access.
2. Secure Your Configuration Stores
Avoid Web Space: Do not store configuration files in web-
accessible directories to prevent unauthorized access through web
vulnerabilities.
Access Control: Implement robust access control mechanisms,
such as Windows ACLs or database permissions, to secure
configuration files, registry keys, or database tables.
Encryption: Encrypt sensitive data like database connection
strings and credentials. This prevents unauthorized access even if
someone gains access to the configuration store.
3. Separate Administration Privileges
Role-Based Access Control (RBAC): Implement RBAC to
ensure that users have only the permissions necessary for their
roles. For instance, content managers should not have access to
financial settings or customer data.
Granular Permissions: Define and enforce granular
permissions based on the specific needs of each role to minimize
the impact of any potential breaches.
4. Use Least Privileged Process and Service Accounts
Least Privilege Principle: Configure service accounts and
processes with the minimum privileges needed to perform their
tasks. This limits the potential damage in case of a security breach.
Process Isolation: Ensure that different processes run under
separate accounts with restricted access to system resources. This
reduces the risk of an attacker escalating their privileges if they
compromise a process.
4.7 Sensitive Data
Below is a breakdown of best practices for securing sensitive data
and handling secrets, including passwords, database connection
strings, and credit card numbers, especially in web applications:
1. Do Not Store Secrets if You Can Avoid It
Storing secrets such as passwords in software can never be
entirely secure. Instead of storing them, verify user knowledge of
the secret by hashing the provided data and comparing it to a
stored hash .
2. Do Not Store Secrets in Code
Hardcoding sensitive information like passwords or connection
strings in your application’s source code is a major vulnerability.
Even if the source code is not directly exposed on the server,
secrets can be extracted from compiled binaries, and security
misconfigurations can lead to exposure.
3. Do Not Store Database Connections, Passwords, or Keys in
Plaintext
Always encrypt sensitive information such as database connection
strings and passwords. Storing them in plaintext makes it easy for
an attacker to access and misuse them. Use robust encryption
algorithms (e.g., AES) to protect this data.

4. Avoid Storing Secrets in the Local Security Authority (LSA)

The Local Security Authority (LSA) is a Windows component used
for managing local security. Storing secrets in the LSA requires
administrative privileges, which goes against the principle of least
privilege and limits scalability. Additionally, LSA has limitations in
terms of storage slots for secrets.
4.8 Session Management
Session management in secure website design involves techniques
to control user sessions, ensuring data integrity and protecting
against unauthorized access. Here are some key practices:
Use Secure Cookies: Store session IDs in secure, HTTP-only
cookies to prevent access from JavaScript and protect against cross-
site scripting (XSS) attacks.
Session ID Rotation: Regenerate session IDs after login and
periodically during a session to minimize the risk of session fixation
attacks.
Set Session Expiry: Define a reasonable session timeout to
automatically log users out after inactivity, reducing exposure to
session hijacking.
Limit Session Scope: Restrict session IDs to specific domains and
paths, preventing them from being accessible across multiple
domains.

Implement Secure Transmission: Use HTTPS to encrypt session

data during transmission, protecting against man-in-the-middle
(MITM) attacks.

Monitor Session Anomalies: Track user sessions for unusual

activity, such as login from multiple IP addresses, and invalidate
sessions when suspicious behavior is detected.
4.9 Cryptography
Cryptography in secure website design involves using encryption
techniques to protect sensitive data from unauthorized access. Key
practices include:
TLS/SSL Encryption: Use Transport Layer Security (TLS) or
Secure Sockets Layer (SSL) to encrypt data transmitted between the
client and server, ensuring data privacy and integrity.
Data Encryption at Rest: Encrypt sensitive data stored in databases
or file systems, using algorithms like AES (Advanced Encryption
Standard) to protect against data breaches.
Hashing for Passwords: Store passwords as cryptographic hashes
(e.g., bcrypt, Argon2) with salt, so even if the database is
compromised, passwords remain secure.
Public Key Infrastructure (PKI): Use public/private key pairs
to manage encryption and digital signatures, ensuring that data
can be encrypted by anyone but only decrypted by the intended
recipient.
Digital Signatures: Use digital signatures to verify the
authenticity of data and ensure it has not been altered, which is
essential for secure document exchanges and transactions.
Key Management: Implement secure key management practices,
such as rotating keys and storing them in secure hardware
modules, to prevent unauthorized key access.
4. 10 Parameter Manipulation

Parameter manipulation attacks involve modifying data exchanged

between the client and the web application, which can occur
through query strings, form fields, cookies, or HTTP headers.
Encrypt Sensitive Cookie State:
Protect sensitive data in cookies (like session identifiers) by
encrypting their contents to prevent unauthorized access or
manipulation.
Prevent Users from Bypassing Checks:
Ensure that checks cannot be bypassed by users manipulating
parameters. Always validate parameters on the server side rather
than relying on client-side checks.
Validate All Values Sent from the Client:
Restrict user input fields and validate all values coming from the
client. Only permit known good values to prevent unwanted
manipulation.

Do Not Trust HTTP Header Information:

Avoid making security decisions based on HTTP header information,
as it can be easily manipulated by attackers. For instance, do not rely
on the Referer header to validate the source of requests.

By implementing these practices, web applications can significantly

reduce the risk of parameter manipulation attacks and enhance their
overall security posture.
4. 11 Exception Management
To implement secure exception handling in web applications and
prevent vulnerabilities like denial of service (DoS) attacks or
information disclosure, you should follow these best practices:
1. Do Not Leak Information to the Client
Avoid exposing sensitive information, such as database schema
details, OS versions, stack traces, or file paths, which can help
attackers exploit your system.
Ensure debug builds, which expose detailed stack traces, are not
used in production.
Provide generic error messages to users that do not reveal
internal workings of your application.
2. Log Detailed Error Messages
Log detailed exceptions on the server side (including stack
traces and exception details) but do not send this detailed
information to the client.
3. Catch Exceptions
Use structured exception handling to catch errors at all
appropriate levels in your application. This helps maintain the
application’s stability and prevents inconsistent states.
When an error occurs, ensure that proper error-handling logic
is in place, especially at the application boundaries (for example,
between presentation and data layers).
4. Centralized Exception Management and Logging
Design a centralized exception management framework that
can handle, log, and monitor all exceptions across the
application.
Use logging frameworks (e.g., NLog, Log4Net) to handle error
logging and ensure exceptions are captured in a secure and
organized way.
4.12 Auditing and Logging
Audit and Log Access Across Application Tiers
Implement logging across all application layers (e.g.,
application-level and platform-specific features like Windows,
IIS, SQL Server).
Consider Identity Flow
Operating System Level: Use Kerberos delegation to flow
user identities, which supports OS-level auditing but may
impact scalability due to connection pooling limitations.
Application Level: Flow user identities within the application
and use trusted identities for back-end access, while generating
correlated audit trails. Ensure server clocks are synchronized.
Log Key Events
Log significant events such as:
Successful and failed login attempts
Data modifications and retrievals
Network communications
Administrative actions (e.g., enabling/disabling logging)
Secure Log Files
Use Windows ACLs to restrict access to log files, making it
harder for attackers to tamper with them.
Limit access to trusted accounts (e.g., administrators).
Back Up and Analyze Log Files Regularly
Regularly remove log files from production servers to
facilitate analysis.
Develop a strategy for retrieving and transferring logs to
offline servers for analysis.
4.13 Design Guidelines
Input Validation Do not trust input; consider centralized input validation. Do not rely on client-
side validation. Be careful with canonicalization issues.
Authentication Partition site by anonymous, identified, and authenticated area. Use strong
passwords. Support password expiration periods and account disablement. Do
not store credentials (use one-way hashes with salt).
Authorization Use least privileged accounts. Consider authorization granularity.
Configuration Use least privileged process and service accounts. Do not store credentials in
Management plaintext. Use strong authentication and authorization on administration
interfaces.
Sensitive Data Avoid storing secrets. Encrypt sensitive data over the wire. Secure the
communication channel.
Session Limit the session lifetime. Secure the channel. Encrypt the contents of
Management authentication cookies. Protect session state from unauthorized access.
Cryptography Do not develop your own. Use tried and tested platform features. Keep
unencrypted data close to the algorithm.
Parameter Encrypt sensitive cookie state. Do not trust fields that the client can manipulate
Manipulation (query strings, form fields, cookies, or HTTP headers).
Exception Use structured exception handling. Do not reveal sensitive application
Management implementation details. Do not log private data such as passwords.
Auditing and Identify malicious behavior. Know what good traffic looks like.
Logging
4.14 Forms and validity
In secure website design, form handling and validation help
protect against data entry errors and security vulnerabilities. Key
practices include:
Server-Side Validation: Always validate data on the server, even
if client-side validation is implemented, to ensure data integrity
and protect against bypassing or manipulation.
Client-Side Validation: Use JavaScript for instant feedback on
form inputs, improving user experience while preventing some
incorrect data from reaching the server.
Sanitization and Encoding: Sanitize and encode user inputs to
prevent injection attacks (e.g., SQL injection, cross-site scripting).
Ensure data is properly handled based on context (e.g., database,
HTML, JavaScript).
Limit Input Types and Lengths: Use appropriate HTML input
types (e.g., email, number, date) and restrict input lengths to reduce
the risk of buffer overflow attacks and ensure data accuracy.

Captcha or ReCAPTCHA: Use captchas to prevent automated

submissions and reduce the risk of spam or brute-force attacks on
forms.

Error Messages: Avoid revealing specific error details in form

responses (like login failure reasons), as these can provide
information useful to attackers.
4.15 Technical implementation
Authentication and Authorization: Use secure authentication
methods like OAuth or multi-factor authentication (MFA), and
enforce role-based access control (RBAC) to restrict user
permissions.

Data Encryption: Use TLS/SSL to secure data in transit, encrypt

sensitive data at rest (e.g., using AES), and employ hashing
algorithms like bcrypt for passwords.

Input Validation and Sanitization: Implement strict input

validation and sanitization on both client and server sides to
prevent injection attacks and XSS.
Content Security Policy (CSP): Configure CSP headers to prevent
malicious scripts from running, protecting against cross-site
scripting (XSS) attacks.

Error Handling and Logging: Configure error handling to avoid

revealing sensitive information in error messages, and use logging to
monitor suspicious activity without logging sensitive data directly.