A security note to web developers on how they can instill safe security design practices on their web development projects.

1. Basic Web Security Design for
Developers
By
John (Troon) Ombagi
A security note to web developers on how they can instill safe security design practices on
their web development projects.
@iLabAfrica

2.   
1
Basic Web Security Design for
Developers
Fundamentals of Information Security
The basic fundamental concept of information security is to establish
Confidentiality, Integrity, and Availability. Only authorized persons
should be able to access certain information. This information should
be trusted (not manipulated or corrupted in any ways) and has to
be there whenever needed.
Security is a tradeoff.
Tightening a website security means sacrificing some functionalities
and/or usability. Take for instance the Google search engine,
imagine answering a captcha challenge each time you want to
make a search request. Irritating, right? Designing your website
security and utilization of security within your web application means
you have to identify and understand what you are trying to protect
(threat modeling). After figuring out your potential threats, you work
towards balancing functionality and usability. For instance a social
media web application can register a client’s session for a longer
time compared to an internet banking website, they both have
different impacts in case of a session abuse.

3.   
2
OWASP TOP 10
OWASP is an open community dedicated to enabling organizations to conceive,
develop, acquire, operate, and maintain applications that can be trusted. The primary
aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and
organizations about the consequences of the most important web application security
weaknesses.
The Top 10 list provides basic techniques to protect against these high risk problem areas
and also provides guidance on how to mitigate these risks
(https://storage.googleapis.com/google-code-archive-
downloads/v2/code.google.com/owasptop10/OWASP%20Top%2010%20-%202013.pdf).
The OWASP community is actively working on OWASP TOP 10 for 2017. Currently (at the
time of writing), release for 2013 remains the official current final release and the most
critical web application security risks are:
 A1 Injection
 A2 Broken Authentication and Session Management
 A3 Cross-Site Scripting (XSS)
 A4 Insecure Direct Object References
 A5 Security Misconfiguration
 A6 Sensitive Data Exposure
 A7 Missing Function Level Access Control
 A8 Cross-Site Request Forgery (CSRF)
 A9 Using Components with Known Vulnerabilities
 A10 Unvalidated Redirects and Forwards

4.   
3
A Security Note for Web Developers.
As a penetration tester, there are common vulnerabilities and misconfigurations that
appear across different web application testing engagements. This section dives into
some of these common vulnerabilities (pointing back to the OWASP Top 10, 2013) from
a security testing point of view and explains how developers can avoid (or minimize)
making these common mistakes. Remember, some of these security issues might have
no impact in your web application, it’s important to understand your threats and what
matters most in the critical parts of your web application.
1). Input Validation (A1, A3)
Any point in your web application where data from untrusted source is take in, should
be looked into with special attention. Untrusted data source is any source that
provides data that you didn’t generate or data coming outside the application like
user inputs. Your intended web application users can be the abusers. Always validate
any data input. This helps cut down injection and XSS attacks.
a) Client-Side then Backend
Many web developers use JavaScript to validate user input and assume this is
enough! Client side data validation can be bypassed by placing a proxy
between a browser and a web application. Make sure you do another data
validation at the back-end before processing requests from the client side.
b) Regex and Blacklisting are hard.
Another big mistake web developers do is trying to create their own filters for
data validation by using regular expressions (regex). Most of these filters can be
bypassed by abusing a rule not captured in the developer’s applied filter. There
is so much bad data to filter, defining these unwanted data (black listing) is
harder compared to defining what a clean data is (whitelisting). Make use
whitelisting, set input size limits, check for data-types and stripe all web tags from
data inputs.

5.   
4
2). Securing sessions (A2, A4, A8)
HTTP is stateless. For persistence, session association and/or authorization, session IDs,
cookies or anything unique that can be stored in the client side and used in HTTP
request employs a sense of session identity. If these elements of identity in a web
application are not well secured, they may break authorization or affect the validity of
user sessions.
a). Don't Reuse Session IDs
If a web application generates a unique session ID each time a user visits, that’s
fine. The problem though, is when a user signs in a web application and the
same session ID generated when unauthenticated is reused when
authenticated. An attacker can perform what is known as a session fixation.
b) Remove Session IDs from URLs
Session IDs should not form part of an URL in any of the web requests. If there is a
redirection to an external web resource, the redirection might leak out the
session ID.
One can use secure HTTP headers for session IDs. If possible, avoid URL
redirections in your web application, if you must them, then specify URLs that are
allowed and notify the user whenever redirecting out to external websites.
c) Track Sessions
A good web application should alert a user whenever an existing valid session is
available in the web server and yet another new session has been created. For
all established sessions, the web-server should be able to track them and make
them expire after a period of time prompting the user to login again. Another
important security design feature web developers can employ is enforcing users
to re-authenticate when doing a critical action on a web application like
deleting an account or making a card transaction.
d) How random is random?
Session IDs should be as random as possible. If an attacker is able to predict the
next session ID a web application is going to generate, the users are at risk.
These session IDs should be unique and hard to brute force.
e) Don’t transmit Session IDs in Clear Text
An attacker sniffing packets in a network can capture session IDs transmitted in
plain text. Using SSL/TLS enables web application users use secure

6.   
5
communication channels that don’t transmit data in clear plain text. Some web
developers assume encoding these IDs solves the problem of transmission over a
protocol that carry data in plain text. Encoding is not encrypting. A base64
encoded string can be decoded.
3) Data Transmission Security (A6)
As mentioned earlier, HTTP is an insecure channel for transmitting data that is supposed
to be kept private like credentials. Using HTTPS forms a secure communication
exchange channel for transmitting data in a web application.
Unfortunately, the green padlock on a client’s browser is not enough. How HTTPS is
implemented matters a lot. A web application should not mix HTTP and HTTPS content.
A web application developer should have in mind users initiating a connection (like
getting a login page) over HTTP or users under a downgrade attack (HTTPS to HTTP).
Below are some Security Header to help improve the secure data exchange channels
in a web application by enforcing secure browser headers. These headers add checks
and controls on the client-side that the server can’t directly control.
i) HTTP Strict Transport Security (HSTS). With HSTS, a user makes only one insecure
connection and upon receiving a response with HSTS header, all other requests will be
made secure by using internal redirection 307 before reaching out to the webserver.
ii) HTTP Public Key Pinning (HPKP) is another great way of protecting the web users
against compromised SSL certificates. Public key pinning allows trusted SSL certificates
to be whitelisted and instructs the browser on how to behave in the future whenever
interacting with the web application in a secure channel.
iii) Lastly, we have Content Security Policy (CSP) which provides a way of white-listing
what resources your web application is allowed to load and which scripts to run. This
prevents attackers from embedding external resource in the web application or
modifying the document object model (DOM).

7.   
6
4) Password Management (A4, A7)
Passwords allow users to be authenticated in a web application, in case of an attack,
they should be in a format that doesn’t expose actual passwords of the registered
users. Passwords should not be stored in the back-end, in plaintext. Use password
salting and peppering algorithms to disguise the initial password before storage.
Don’t roll out your own crypto (unless you are good at it and whatever you have
created has been tested and approved by other crypto experts). Use provided crypto
libraries within your development frameworks. For instance, here are some publicly
tested and approved cryptographic libraries you can use in your web application,
bcrypt, PBKDF2 (key derivation function) or scrypt.
I) Password validation
Some web developers force users to use a certain pattern in their password
creation. This is not entirely bad but still it discourages the users from creating
complex passwords they can remember. Instead just use an indicator for strong
and weak passwords (you can use something like this
http://davidstutz.github.io/bootstrap-strength-meter without enforcing a
particular format. Also,
a strict password
pattern means an
attacker can use a
rule-based password
cracking technique
which increases the
chances of positive
results.

8.   
7
ii) Account Enumeration
Login and password rest forms should not be too detailed. If a user doesn’t exist
in a web application or maybe the password is wrong, give a generic message
that an attack cannot tell which one of the two is valid and which one is not.
On password reset make the user submit something he/she knows or he/she has
before disclosing any personal identifiable information (PII). For example
https://accounts.ecitizen.go.ke/forgot-password has a very bad password rest
feature (you can enter anyone’s/random email or increment your ID number
with 1 to get another person’s PII).
If a user provides an email or ID, let the user provide the phone number used
during registration and send a validation token via SMS for him/her to continue
with the reset process.
iii) Brute-force Attacks
A good web application should counter any automated tool that send a lot of
web requests in a very short time. Introduce a captcha on every critical web
form in your website or simply show the captcha once you notice presences of
an automation tool sending requests e.g. web headers from such known tools
(like web scanners) and request time (if a lot of request are done in milliseconds
and originate from a single user, it is likely an automation).
Another way of countering brute-force attacks is using unique IDs for each HTTP
response that must be included in the HTTP requests. This ID should not be reused
or easy to predict the next one. One can also throttle requests from a particular
client that is suspected of sending automated/malicious requests.

9.   
8
5) Web Deployment (A6, A5, A9)
Choosing where to host your web application is very important. Some web apps
might require a dedicated hosting rather than a shared hosting. Another things to
consider for your hosting is scalability, availability, extra layer of security (like against
DOS attacks) and it should be a reputable hosting company.
Other things that can go wrong in web deployment:
 Running other multiple services that you don’t need on a web server.
 Using outdated software/applications on a web-server
 Not updating a web server’s OS and running old/unpatched applications
 Binding critical services (like MySQL) on a public IP
o Use 127.0.0.1 unless it’s intended to be accessed remotely by other
services on a public IP
 Using a super user account for every service running on a server
o Employ principle of lest privilege.
 Not setting folder permissions on the web server
 Using default credentials (a common sucker!)
 Not having a backup policy
o In case things get out of control, you should be able to bounce back –
business continuity is a real thing
 Hosting in countries under oppressive regimes or civil war etc.
o Do you want free web hosting in Turkmenistan?
Defense in depth is always important when trying to secure anything. So installing a
Web Application Firewall can reduce some of the aforementioned common attacks.
Log everything on your web server and make sure the time is correctly set (use
Network Time Protocol), this will save headaches when responding to a security
incident and recreating events timeline.
John Ombagi,
IT Security Assistant,
@iLabAfrica
jnyabuti@strathmore.edu