Unit VI: Security in Web Applications - Web Technologies II - BCA Notes (Pokhara University)

Breaking

Friday, August 23, 2019

Unit VI: Security in Web Applications - Web Technologies II

Web Application Security Fundamentals:

Modern web development comes with a variety of challenges that developers have to consider, such as accessibility, responsive design, and security. Unfortunately, these things sometimes go overlooked or are outright ignored, especially when it comes to security.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

According to the Cost of Data Breach study done by IBM in 2017, the average size of data being affected in breaches is increasing, and the odds of an organization being breached are now one in four. And it isn’t just Fortune 500 or publicly traded tech companies that are falling victim data breaches can affect any organization that exists on the web.

Data is a massive asset to hackers, and they are seeking out more than usernames, passwords, and credit card numbers. So even if we don’t think we’re a target, it’s important to protect ourselves and our users from vulnerabilities that may be present in our app. This keeps us and our user safe and builds trust between us and merchants by showing that we take security seriously.

Foundation of Cyber Security:

From “malicious insider” to “ransomware,” cybersecurity is riddled with a lot of terms that paint a potent picture of the daily risks that businesses face from online criminals. Before a business owner considers any technology protection solution, he or she needs to have a baseline understanding of those risks and basic components that work to anchor that system.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Cyber Security Elements That Provide the Protective Foundation for Business:

1. Authentication:

The process of determining the identity of a user attempting to access a network, usually through the use of a password, certificate, PIN, or other information that can be used to validate identity over a computer network. Passwords are the first line of defence for network security. A good password mixes letters, numbers, and punctuation along with symbols or non-alphanumeric characters (like?!$%). Passwords also underscore the importance of employee education about security best practices, such as not basing their passwords on details from their lives that are surprisingly simple to find online, like their mother’s maiden name.

2. Authorization:

Authorization address the question: what can we do? It is the process that governs the resources and operations that the authenticated client is permitted to access resources include files, databases, tables, rows and so on. In other words, Authorization is the process of verifying that we have access to something. Gaining access to a resource (e.g. directory on a hard disk) because the permissions configured on it allows us access is authorization.

3. Antivirus:

Antivirus has become the generic de-facto term most users refer to when thinking of security for their computers. When a piece of malicious software code (the virus) is discovered, it is given a signature which identifies it as such and the antivirus software is updated with the latest signatures to block the known code. This is why it’s important to keep our antivirus software up to date to block the latest threats. However, with the complexity and the sophistication of the latest threats, an antivirus alone isn’t enough to block the new, never-before-seen threats, which is why businesses need to apply multiple layers of security found in more robust endpoint protection solutions.

4. Endpoint Protection:

Cybercriminals have become skilled at creating viruses that evade traditional antivirus detection methods. Endpoint protection solutions combine multiple layers of protection and advanced techniques of detection, which go beyond basic antivirus. Business-grade endpoint protection employs layers, such as firewalls, to block certain network traffic, Web browser security which can block malicious websites, and behavioural analysis to detect suspicious program activities that “behave” like known malware.

5. Encryption:

Encryption is security, it’s a standard practice of scrambling or encoding data to prevent unauthorized users from reading or tampering with the data. With growing concerns over data breaches, cyber-attacks, and the need to comply with security laws, the use of encryption is steadily increasing, according to a study by the Ponemon Institute. One Challenge Company’s face in adopting a data encryption strategy is understanding exactly where their crucial data is demonstrating the need for a security audit.

6. Website Security/SSL:

If we have an online e-commerce website or transact business online, then securing online transactions and safeguarding customer information is critical to our business’s growth and success. Secure socket layer encryption (SSL), is a website security solution to encrypt our online transactions and keep our website safe from attacks, plus it demonstrates to our customers that we are taking a strong proactive stance to protect their information from potential attackers. Online shoppers are more likely to enter their credit card and/or other confidential financial information into a website with SSL.

7. System Recovery:

The process of rebuilding a computer system after a disaster so that it's operating system and other software can be reinstalled.

8. Backup & Recovery:

The process of regularly backing up our systems and files to another device, media, or location, essentially to have a second copy of our files and data readily available in case of an outage, natural disaster, or loss or theft of our equipment.

Security Threats:

It’s a dangerous world out there in the World Wide Web. Just as our mother may have told us to never talk to strangers, the same advice holds true for the virtual world. We may know to be wary of giving strangers our business bank account details. But can we be sure the website we’re logging into is that of our bank and not a forgery created by a cybercriminal?

Cybercriminals use many different methods to lure us into parting with our confidential personal or business information. As a small company doing business on the web, we need to be aware of these methods so we can be extra vigilant when online.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Common Security Threats We May Come Across:

1. Malware:

Malware is short for “malicious software.” Wikipedia describes malware as a term used to mean a “variety of forms of hostile, intrusive, or annoying software or program code.” Malware could be computer viruses, worms, Trojan horses, dishonest spyware, and malicious rootkits all of which are defined below.

2. Computer Virus:

A computer virus is a small piece of software that can spread from one infected computer to another. The virus could corrupt, steal, or delete data on our computer even erasing everything on our hard drive. A virus could also use other programs like our email program to spread itself to other computers.

3. Rogue Security Software:

Have we ever seen a pop-up window that advertises a security update or alert? It appears legitimate and asks us to click on a link to install the “update” or “remove” unwanted malicious software that it has apparently detected. This could be rogue security software designed to lure people into clicking and downloading malicious software. Microsoft has a useful webpage that describes rogue security software and how we can protect ourselves.

4. Trojan Horse:

Users can infect their computers with Trojan horse software simply by downloading an application they thought was legitimate but was in fact malicious. Once inside our computer, a Trojan horse can do anything from record our passwords by logging keystrokes (known as a keystroke logger) to hijacking our webcam to watch and record our every move.

In February 2010, a Guardian Analytics and Ponemon Institute study of 500 small businesses in the U.S. found that 55 percent of respondents experienced a fraud attack in the last 12 months. The study reports that well-funded cybercriminals executed a full-scale assault on authentication, leveraging widespread infection of end-user computers with banking Trojans to sneak into online banking accounts completely undetected.”

5. Malicious Spyware:

Malicious spyware is used to describe the Trojan application that was created by cybercriminals to spy on their victims. An example would be keylogger software that records a victim’s every keystroke on his or her keyboard. The recorded information is periodically sent back to the originating cybercriminal over the Internet. Keylogging software is widely available and is marketed to parents or businesses that want to monitor their kids’ or employees’ Internet usage.

6. Computer Worm:

A computer worm is a software program that can copy itself from one computer to another, without human interaction. Worms can replicate in great volume and with great speed. For example, a worm can send copies of itself to every contact in our email address book and then send itself to all the contacts in our contacts’ address books.

Because of their speed of infection, worms often gain notoriety overnight infecting computers across the globe as quickly as victims around the world switch them on and open their email. This happened with the Conficker worm (also known as Downadup), which, in just four days, had more than tripled the number of computers, they infected to 8.9 million.

7. Botnet:

botnet is a group of computers connected to the Internet that has been compromised by a hacker using a computer virus or Trojan horse. An individual computer in the group is known as a “zombie” computer.

The botnet is under the command of a “bot herder” or a “botmaster,” usually to perform nefarious activities. This could include distributing spam to the email contact addresses on each zombie computer, for example. If the botnet is sufficiently big in number, it could be used to access a targeted website simultaneously in what’s known as a denial-of-service (DoS) attack. The goal of a DoS attack is to bring down a web server by overloading it with access requests. Popular websites such as Google and Twitter have been victims of DoS attacks.

8. Spam:

Spam in the security context is primarily used to describe email spam unwanted messages in our email inbox. Spam, or electronic junk mail, is a nuisance as it can clutter our mailbox as well as potentially take up space on our mail server. Unwanted junk mail advertising items we don’t care for is harmless, relatively speaking. However, spam messages can contain links that when clicked on could go to a website that installs malicious software onto our computer.

9. Phishing:

Phishing scams are fraudulent attempts by cybercriminals to obtain private information. Phishing scams often appear in the guise of email messages designed to appear as though they are from legitimate sources. For example, the message would try to lure us into giving us personal information by pretending that our bank or email service provider is updating its website and that we must click on the link in the email to verify our account information and password details.

10. Rootkit:

According to TechTarget, a rootkit is a collection of tools that are used to obtain administrator-level access to a computer or a network of computers. A rootkit could be installed on our computer by a cybercriminal exploiting a vulnerability or a security hole in a legitimate application on our PC and may contain spyware that monitors and records keystrokes.

Rootkits gained notoriety when, in 2005, a security blogger discovered that a copy-protection tool inside music CDs from Sony BMG Music Entertainment was secretly installing a rootkit when users copied the CD onto their computers. At the time, security expert Bruce Schneier warned that the rootkit could allow a hacker to “gain and maintain access to our system and we wouldn’t know it.”

Web Security Vulnerabilities:

OWASP or Open Web Security Project is a non-profit charitable organization focused on improving the security of software and web applications. The organization publishes a list of top web security vulnerabilities based on the data from various security organizations. The web security vulnerabilities are prioritized depending on exploitability, detectability and impact on software.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

1. Exploitability:

What is needed to exploit the security vulnerability? Highest exploitability when the attack needs a web browser and lowest being advanced programming and tools.

2. Detectability:

How easy is it to detect the threat? Highest is the information displayed on URL, Form or Error message and lowest being source code.

3. Impact or Damage:

How much damage will be done if the security vulnerability is exposed or attacked? Highest being complete system crash and lowest being nothing at all.

OWASP Top 10 Most Important Security Vulnerabilities:

1. SQL Injection:

The injection is a security vulnerability that allows an attacker to alter backend SQL statements by manipulating the user-supplied data. Injection occurs when the user input is sent to an interpreter as part of a command or query and trick the interpreter into executing unintended commands and gives access to unauthorized dataThe SQL command which when executed by web application can also expose the back-end database.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Implication:
a) An attacker can inject malicious content into the vulnerable fields.
b) Sensitive data like User Names, Passwords, etc. can be read from the database.
c) Database data can be modified (Insert/Update/ Delete).
d) Administration Operations can be executed on the database

Vulnerable Objects:
a) Input Fields
b) URLs interacting with the database.

Recommendations:
a) Whitelisting the input fields
b) Avoid displaying detailed error messages that are useful to an attacker.

2. Cross-Site Scripting:

Cross-Site Scripting is also shortly known as XSS. XSS vulnerabilities target scripts embedded in a page that is executed on the client-side i.e. user browser rather than at the server-side. These flaws can occur when the application takes untrusted data and send it to the web browser without proper validation.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Attackers can use XSS to execute malicious scripts on the users in this case victim browsers. Since the browser cannot know if the script is trusty or not, the script will be executed, and the attacker can hijack session cookies, deface websites, or redirect the user to unwanted and malicious websites. XSS is an attack which allows the attacker to execute the scripts on the victim's browser.

Implication:
a) Making the use of this security vulnerability, an attacker can inject scripts into the application, can steal session cookies, deface websites, and can run malware on the victim's machines.

Vulnerable Objects:
a) Input Fields
b) URLs

Recommendations:
a) White Listing input fields
b) Input-Output encoding

3. Broken Authentication and Session Management:

The websites usually create a session cookie and session ID for each valid session and these cookies contain sensitive data like username, password, etc. When the session is ended either by logout or browser closed abruptly, these cookies should be invalidated i.e. for each session there should be a new cookie.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

If the cookies are not invalidated, the sensitive data will exist in the system. For example, a user using a public computer (Cyber Cafe), the cookies of the vulnerable site sits on the system and exposed to an attacker. An attacker uses the same public computer after some time, the sensitive data is compromised.

In the same manner, a user using a public computer, instead of logging off, he closes the browser abruptly. An attacker uses the same system, when browses the same vulnerable site, the previous session of the victim will be opened. The attacker can do whatever he wants to do from stealing profile information, credit card information, etcA check should be done to find the strength of authentication and session management. Keys, session tokens, cookies should be implemented properly without compromising passwords.

Implication:
a) Making use of this vulnerability, an attacker can hijack a session, gain unauthorized access to the system which allows disclosure and modification of unauthorized information.
b) The sessions can be high jacked using stolen cookies or sessions using XSS.

Vulnerable Objects:
a) Session IDs exposed on URL can lead to a session fixation attack.
b) Session IDs same before and after logout and login.
c) Session Timeouts are not implemented correctly.
d) Application is assigning same session ID for each new session.
e) Authenticated parts of the application are protected using SSL and passwords are stored in a hashed or encrypted format.
f) The session can be reused by a low privileged user.

Recommendations:
a) All the authentication and session management requirements should be defined as per the OWASP Application Security Verification Standard.
b) Never expose any credentials in URLs or Logs.
c) Strong efforts should be also made to avoid XSS flaws which can be used to steal session IDs.

4. Insecure Direct Object References:

It occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key as in URL or as a FORM parameter. The attacker can use this information to access other objects and can create a future attack to access the unauthorized data.

Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp
Implication:
a) Using this vulnerability, an attacker can gain access to unauthorized internal objects, can modify data or compromise the application.

Vulnerable Objects:
a) In the URL.

Recommendations:
a) Implement access control checks.
b) Avoid exposing object references in URLs.
c) Verify authorization to all reference objects.

5. Cross-Site Request Forgery:

Cross-Site Request Forgery is a forged request came from the cross-site. CSRF attack is an attack that occurs when a malicious website, email, or the program causes a user's browser to perform an unwanted action on a trusted site for which the user is currently authenticated.

Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp
A CSRF attack forces a logged-on victim's browser to send a forged HTTP request, including the victim's session cookie and any other automatically included authentication information, to a vulnerable web application. A link will be sent by the attacker to the victim when the user clicks on the URL when logged into the original website, the data will be stolen from the website.

Implication:
a) Using this vulnerability as an attacker can change user profile information, change status, create a new user on admin behalf, etc.

Vulnerable Objects:
a) User Profile page
b) User account forms
c) Business transaction page

Recommendation:
a) Mandate the user's presence while performing sensitive actions.
b) Implement mechanisms like CAPTCHA, Re-Authentication, and Unique Request Tokens.

6. Security Misconfiguration:

Security Configuration must be defined and deployed for the application, frameworks, application server, web server, database server, and platform. If these are properly configured, an attacker can have unauthorized access to sensitive data or functionality. Sometimes such flaws result in complete system compromise. Keeping the software up to date is also good security.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Implication:
a) Making use of this vulnerability, the attacker can enumerate the underlying technology and application server version information, database information and gain information about the application to mount a few more attacks.

Vulnerable Objects:
a) URL
b) Form Fields
c) Input fields

Recommendations:
a) A strong application architecture that provides good separation and security between the components.
b) Change default usernames and passwords.
c) Disable directory listings and implement access control checks.

7. Insecure Cryptographic Storage:

Insecure Cryptographic Storage is a common vulnerability which exists when the sensitive data is not stored securely. The user credentials, profile information, health details, credit card information, etc. come under sensitive data information on a website. This data will be stored on the application database. When this data is stored improperly by not using encryption or hashing*, it will be vulnerable to the attackers. (*Hashing is the transformation of the string characters into shorter strings of fixed length or a key. To decrypt the string, the algorithm used to form the key should be available)
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Implication:
a) By using this vulnerability, an attacker can steal, modify such weakly protected data to conduct identity theft, credit card fraud or other crimes.

Vulnerable Objects:
a) Application database.

Recommendations:
a) Ensure appropriate strong standard algorithms. Do not create own cryptographic algorithms. Use only approved public algorithms such as AES, RSA public key cryptography, and SHA-256, etc.
b) Ensure offsite backups are encrypted, but the keys are managed and backed up separately.

8. Failure To Restrict URL Access:

Web applications check URL access rights before rendering protected links and buttons. Applications need to perform similar access control checks each time these pages are accessed. In most of the applications, the privileged pages, locations and resources are not presented to the privileged users. By an intelligent guess, an attacker can access privilege pages. An attacker can access sensitive pages, invoke functions and view confidential information.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp
Implication:
a) Making use of this vulnerability attacker can gain access to the unauthorized URLs, without logging into the application and exploit the vulnerability. An attacker can access sensitive pages, invoke functions and view confidential information.

Vulnerable Objects:
a) URLs

Recommendations:
a) Implement strong access control checks.
b) Authentication and authorization policies should be role-based.
c) Restrict access to unwanted URLs.

9. Insufficient Transport Layer Protection:

Deals with information exchange between the user (client) and the server (application). Applications frequently transmit sensitive information like authentication details, credit card information, and session tokens over a network. By using weak algorithms or using expired or invalid certificates or not using SSL can allow the communication to be exposed to untrusted users, which may compromise a web application and or steal sensitive information.

Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Implication:
a) Making use of this web security vulnerability, an attacker can sniff legitimate user's credentials and gaining access to the application.
b) Can steal credit card information.

Vulnerable Objects:
a) Data sent over the network.

Recommendations:
a) Enable secure HTTP and enforce credential transfer over HTTPS only.
b) Ensure our certificate is valid and not expired.

10. Unvalidated Redirects and Forwards:

The web application uses few methods to redirect and forward users to other pages for an intended purpose. If there is no proper validation while redirecting to other pages, attackers can make use of this and can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Implication:
a) An attacker can send a URL to the user that contains a genuine URL appended with encoded malicious URL. A user by just seeing the genuine part of the attacker sent URL can browse it and may become a victim.

Recommendations:
a) Simply avoid using redirects and forwards in the application. If used, do not involve using user parameters in calculating the destination.
b) If the destination parameters can't be avoided, ensure that the supplied value is valid, and authorized for the user.

Security Attacks:

An attack is a specific technique used to exploit a vulnerability. For example, a threat could be a denial of service. Vulnerability is in the design of the operating system, and an attack could be a "ping of death." There are two general categories of attacks, passive and active.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Passive attacks are very difficult to detect because there is no overt activity that can be monitored or detected. Examples of passive attacks would be packet sniffing or traffic analysis. These types of attacks are designed to monitor and record traffic on the network. They are usually employed for gathering information that can be used later in active attacks.

Active attacks, as the name implies, employ more overt actions on the network or system. As a result, they can be easier to detect, but at the same time, they can be much more devastating to a network. Examples of this type of attack would be a denial-of-service attack or active probing of systems and networks.

The Web Application can be Targeted by Cyber Criminals with Different Attacks such as:

1. Bots and Web Scraping:

It is a kind of software which automates iterative actions to prevent the user from doing the same actions over and over again. Just to be clear, bots record Google researches to show better results. They award deserving websites in terms of visibility. However, we have both “good” bots and “bad” bots. Bad bots generate traffic as well but this traffic is infected as well as the bot.

Basically, this is why a bad bot can be used for web scraping. This action consists of extrapolating data from a website or a web application. As a matter of fact, this is a plague of the internet, recent statistic shows 20% of the whole traffic is bad-bots-traffic. What does this mean? It means that potentially every website we browse, even though it’s marked as safe, could expose us to data theft.

Data theft does not always imply the theft of payment-related data. It can be simple memorization of our e-mail address which could be used later by attackers to spam us and run a phishing attack. Bad bots can pave the way to DDoS attacks as well.

2. DDOS Attack:

DDoS stands for Distributed Denial of Service. This specific attack, to be carried out, needs many IP addresses, this is why its origins are often hard to trace. A DDoS attack bombs a system with requests and finally crashes it.

We Have Three Main Types of DDoS Attacks:

a. IP Spoofing:
This is the most common DDoS attack mainly because it is successful for hackers who need to have non-authorized access to the system. Through the spoofing, packages of IP addresses are created and these packages are useful to mask the identity of the attacker. Basically, this means that the cybercriminal uses fake IPs that prevent the system from identifying the origin. The most common techniques of IP spoofing are UDP flood and ICMP flood. The first one is about the stress of the system through a lot of requests containing UDP (communication security protocol) datagrams. The second one, with the same methodology, uses the ICMP (Internet Control Message Protocol) protocol.

b. Protocol Attacks:
The DDoS attack can affect the security protocol of the web application through techniques such as the Ping of Death or the Smurf.

c. GET/POST Flood:
The attacker exploits an apparently not infected HTTP (security protocol for web pages) or a POST (Power-On-Self-Test, the auto-analysis phase of a system) to start DDoS attacks. This is an effortless technique for the hackers but it requires deeper knowledge. This is why only expert hackers can carry out such attacks.

3. Cross-Site Scripting:

Cross-Site Scripting or XSS is one of the most dangerous attacks as far as web applications are concerned. Basically, it implies the input of snippets, infected pieces of JavaScript that the user is going to run. While the users click on the infected URL, he/she allows the hacker to have access and obtain personal data. Cross-Site Scripting is also used to edit the content of a page to redirect the user to another infected web application.

4. SQL Injection Attack:

SQL is the standard language as far as databases are concerned. An SQL Injection attack consists of injecting infected elements that the database might consider as legit. In this case, the database is open to data theft that could affect both users and admins. Hackers could create administrative accounts to control web application. An SQL Injection attack can lead to very dangerous consequences: What if an attacker steals information such as addresses and telephone numbers in addition to payment data?

5. Malware:

We have different kinds of malware basing on the purpose they have (ransomware, Trojan, spyware …). Once a malware enters a system, a cybercriminal can get the full control of it. This is why protecting our web applications from malware is crucial: the number of cyber-attacks led using malware is very high and even if it seems that hackers are moving to cryptocurrencies mining, the threat remains.

Security Principles:

These principles are taken from the OWASP Development Guide and comply with the security principles outlined in Michael Howard and David LeBlanc’s book Writing Secure Code. They include:
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

1. Minimise Attack Surface Area:

Every time a programmer adds a feature to their application, they are increasing the risk of a security vulnerability. The principle of minimising attack surface area restricts the functions that users are allowed to access, to reduce potential vulnerabilities.

For example, we might code a search feature into an application. That search feature is potentially vulnerable to file inclusion attacks and SQL injection attacks. The developer could limit access to the search function, so only registered users could use it, reducing the attack surface and the risk of a successful attack.

2. Establish Secure Defaults:

This principle states that the application must be secure by default. That means a new user must take steps to obtain higher privileges and remove additional security measures (if allowed). Establishing safe defaults means there should be strong security rules for how user registrations are handled, how often passwords must be updated, how complex passwords should be and so on. Application users may be able to turn off some of these features, but they should be set to a high-security level by default.

3. The Principle Of Least Privilege:

The Principle of Least Privilege (POLP) states that a user should have the minimum set of privileges required to perform a specific task. The POLP can be applied to all aspects of a web application, including user rights and resource access. For example, a user who is signed up to a blog application as an “author” should not have administrative privileges that allow them to add or remove users. They should only be allowed to post articles to the application.

4. The Principle Of Defence In-Depth:

The principle of defence in depth states that multiple security controls that approach risks in different ways are the best option for securing an application. So, instead of having one security control for user access, we would have multiple layers of validation, additional security auditing tools, and logging tools. For example, instead of letting a user login with just a username and password, we would use an IP check, a Captcha system, logging of their login attempts, brute force detection and so on.

5. Fail Securely:

There are many reasons why a web application would fail to process a transaction. Perhaps a database connection failed, or the data inputted from a user was incorrect. This principle states that applications should fail securely. Failure should not give the user additional privileges, and it should not show the user sensitive information like database queries or logs.

6. Don’t Trust Services:

Many web applications use third-party services for accessing additional functionality or obtaining additional data. This principle states that we should never trust these services from a security perspective. That means the application should always check the validity of data that third-party services send and not give those services high-level permissions within the app.

7. Separation Of Duties:

Separation of duties can be used to prevent individuals from acting fraudulently. For example, a user of an eCommerce website should not promote to be an administrator as they will be able to alter orders and give themselves products. The reverse is also true, an administrator should not have the ability to do things that customers do, like order items from the front end of the website.

8. Avoid Security By Obscurity:

This OWASP principle states that security by obscurity should never be relied upon. If our application requires its administration URL to be hidden so it can remain secure, then it is not secure at all. There should be sufficient security controls in place to keep our application safe without hiding core functionality or source code.

9. Keep Security Simple:

Developers should avoid the use of very sophisticated architecture when developing security controls for their applications. Having very complex mechanisms can increase the risk of errors.

10. Fix Security Issues Correctly:

If a security issue has been identified in an application, developers should determine the root cause of the problem. They should then repair it and test the repairs thoroughly. If the application uses design patterns, the error may likely be present in multiple systems. Programmers should be careful to identify all affected systems.

Threats and Countermeasures:

Anatomy of an Attack:

By understanding the basic approach used by attackers to target our Web application, we will be better equipped to take defensive measures because we will know what we are up against. The basic steps in attacker methodology are summarized below and illustrated in Figure below.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

1. Survey and Assess:

Surveying and assessing the potential target are done in tandem. The first step an attacker usually takes is to survey the potential target to identify and assess its characteristics. These characteristics may include its supported services and protocols together with potential vulnerabilities and entry points. The attacker uses the information gathered in the survey and assess the phase to plan an initial attack.

For example, an attacker can detect a cross-site scripting (XSS) vulnerability by testing to see if any controls in a Web page echo back output.

2. Exploit and Penetrate:

Having surveyed a potential target, the next step is to exploit and penetrate. If the network and host are fully secured, our application (the front gate) becomes the next channel for the attack.

For an attacker, the easiest way into an application is through the same entrance that legitimate users use. For example, through the application's log on page or a page that does not require authentication.

3. Escalate Privileges:

After attackers manage to compromise an application or network, perhaps by injecting code into an application or creating an authenticated session with the Microsoft® Windows® 2000 operating system, they immediately attempt to escalate privileges. Specifically, they look for administration privileges provided by accounts that are members of the Administrators group. They also seek out the high level of privileges offered by the local system account.

Using least privileged service accounts throughout our application is a primary defence against privilege escalation attacks. Also, many network-level privilege escalation attacks require an interactive logon session.

4. Maintain Access:

Having gained access to a system, an attacker takes steps to make future access easier and to cover his or her tracks. Common approaches for making future access easier include planting back-door programs or using an existing account that lacks strong protection. Covering tracks typically involves clearing logs and hiding tools. As such, audit logs are a primary target for the attacker.

Log files should be secured, and they should be analysed regularly. Logfile analysis can often uncover the early signs of an attempted break-in before damage is done.

5. Deny Service:

Attackers who cannot gain access often mount a denial of service attack to prevent others from using the application. For other attackers, the denial of service option is their goal from the outset. An example is the SYN flood attack, where the attacker uses a program to send a flood of TCP SYN requests to fill the pending connection queue on the server. This prevents other users from establishing network connections.

Network Threats and Countermeasures:

The primary components that make up our network infrastructure are routers, firewalls, and switches. They act as the gatekeepers guarding our servers and applications from attacks and intrusions. An attacker may exploit poorly configured network devices. Common vulnerabilities include weak default installation settings, wide-open access controls, and devices lacking the latest security patches.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

1. Information Gathering:

Network devices can be discovered and profiled in much the same way as other types of systems. Attackers usually start with port scanning. After they identify open ports, they use banner grabbing and enumeration to detect device types and to determine the operating system and application versions. Armed with this information, an attacker can attack known vulnerabilities that may not be updated with security patches.

Countermeasures To Prevent Information Gathering Include:
a) Configure routers to restrict their responses to footprinting requests.
b) Configure operating systems that host network software (for example, software firewalls) to prevent footprinting by disabling unused protocols and unnecessary ports.

2. Sniffing:

Sniffing or eavesdropping is the act of monitoring traffic on the network for data such as plaintext passwords or configuration information. With a simple packet sniffer, an attacker can easily read all plaintext traffic. Also, attackers can crack packets encrypted by lightweight hashing algorithms and can decipher the payload that we considered to be safe. The sniffing of packets requires a packet sniffer in the path of the server/client communication.

Countermeasures To Help Prevent Sniffing Include:
a) Use strong physical security and proper segmenting of the network. This is the first step in preventing traffic from being collected locally.
b) Encrypt communication fully, including authentication credentials. This prevents sniffed packets from being usable to an attacker. SSL and IPSec (Internet Protocol Security) are examples of encryption solutions.

3. Spoofing:

Spoofing is a means to hide one's true identity on the network. To create a spoofed identity, an attacker uses a fake source address that does not represent the actual address of the packet. Spoofing may be used to hide the original source of an attack or to work around network Access Control Lists (ACLs) that are in place to limit host access based on source address rules.

Although carefully crafted spoofed packets may never be tracked to the original sender, a combination of filtering rules prevents spoofed packets from originating from our network, allowing us to block obviously spoofed packets.

Countermeasures To Prevent Spoofing Include:
a) Filter incoming packets that appear to come from an internal IP address at our perimeter.
b) Filter outgoing packets that appear to originate from an invalid local IP address.

4. Session Hijacking:

Also known as the man in the middle attacks, session hijacking deceives a server or a client into accepting the upstream host as the actual legitimate host. Instead, the upstream host is an attacker's host that is manipulating the network so the attacker's host appears to be the desired destination.

Countermeasures To Help Prevent Session Hijacking Include:
a) Use encrypted session negotiation.
b) Use encrypted communication channels.
c) Stay informed of platform patches to fix TCP/IP vulnerabilities, such as predictable packet sequences.

5. Denial of Service:

Denial of service denies legitimate users access to a server or services. The SYN flood attack is a common example of a network-level denial of service attack. It is easy to launch and difficult to track. The attack aims to send more requests to a server than it can handle. The attack exploits a potential vulnerability in the TCP/IP connection establishment mechanism and floods the server's pending connection queue.

Countermeasures To Prevent Denial Of Service Include:
a) Apply the latest service packs.
b) Harden the TCP/IP stack by applying the appropriate registry settings to increase the size of the TCP connection queue, decrease the connection establishment period and employ dynamic backlog mechanisms to ensure that the connection queue is never exhausted.
c) Use a network Intrusion Detection System (IDS) because these can automatically detect and respond to SYN attacks.

Host Threats and Countermeasures:

Host threats are directed at the system software upon which our applications are built. This includes Windows 2000, Internet Information Services (IIS), the .NET Framework, and SQL Server 2000, depending upon the specific server role.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

1. Viruses, Trojan Horses, and Worms:

A virus is a program that is designed to perform malicious acts and cause disruption to our operating system or applications. A Trojan horse resembles a virus except that the malicious code is contained inside what appears to be a harmless data file or executable program. A worm is similar to a Trojan horse except that it self-replicates from one server to another.

Worms are difficult to detect because they do not regularly create files that can be seen. They are often noticed only when they begin to consume system resources because the system slows down or the execution of other programs halt. The Code Red Worm is one of the most notorious to afflict IIS; it relied upon a buffer overflow vulnerability in a particular ISAPI filter.

Although these three threats are actual attacks, together they pose a significant threat to Web applications, the hosts these applications live on, and the network used to deliver these applications. The success of these attacks on any system is possible through many vulnerabilities such as weak defaults, software bugs, user error, and inherent vulnerabilities in Internet protocols.

Countermeasures We Can Use Against Viruses, Trojan Horses, And Worms Include:
a) Stay current with the latest operating system service packs and software patches.
b) Block all unnecessary ports at the firewall and host.
c) Disable unused functionality including protocols and services.
d) Harden weak, default configuration settings.

2. Footprinting:

Examples of footprinting are port scans, ping sweeps, and NetBIOS enumeration that can be used by attackers to glean valuable system-level information to help prepare for more significant attacks. The type of information potentially revealed by footprinting includes account details, operating system and other software versions, server names, and database schema details.

Countermeasures To Help Prevent Footprinting Include:
a) Disable unnecessary protocols.
b) Lockdown ports with the appropriate firewall configuration.
c) Use TCP/IP and IPSec filters for defence in depth.
d) Configure IIS to prevent information disclosure through banner grabbing.
e) Use an IDS that can be configured to pick up footprinting patterns and reject suspicious traffic.

3. Password Cracking:

If the attacker cannot establish an anonymous connection with the server, he or she will try to establish an authenticated connection. For this, the attacker must know a valid username and password combination. If we use default account names, we are giving the attacker a head start. Then the attacker only has to crack the account's password. The use of blank or weak passwords makes the attacker's job even easier.

Countermeasures To Help Prevent Password Cracking Include:
a) Use strong passwords for all account types.
b) Apply lockout policies to end-user accounts to limit the number of retry attempts that can be used to guess the password.
c) Do not use the default account names, and rename standard accounts such as the administrator's account and the anonymous Internet user account used by many Web applications.
d) Audit failed logins for patterns of password hacking attempts.

4. Denial of Service:

Denial of service can be attained by many methods aimed at several targets within our infrastructure. At the host, an attacker can disrupt service by brute force against our application or an attacker may know of a vulnerability that exists in the service our application is hosted in or in the operating system that runs our server.

Countermeasures To Help Prevent Denial Of Service Include:
a) Configure applications, services, and operating system with denial of service in mind.
b) Stay current with patches and security updates.
c) Harden the TCP/IP stack against denial of service.
d) Make sure account lockout policies cannot be exploited to lockout well-known service accounts.
e) Make sure application is capable of handling high volumes of traffic and that thresholds are in place to handle abnormally high loads.
f) Review the application's failover functionality.
g) Use an IDS that can detect potential denial of service attacks.

5. Arbitrary Code Execution:

If an attacker can execute malicious code on our server, the attacker can either compromise server resources or mount further attacks against downstream systems. The risks posed by arbitrary code execution increase if the server process under which the attacker's code runs is over-privileged. Common vulnerabilities include weak IID configuration and unpatched servers that allow path traversal and buffer overflow attacks, both of which can lead to arbitrary code execution.

Countermeasures To Help Prevent Arbitrary Code Execution Include:
a) Configure IIS to reject URLs with "../" to prevent path traversal.
b) Lockdown system commands and utilities with restricted ACLs.
c) Stay current with patches and updates to ensure that newly discovered buffer overflows are speedily patched.

6. Unauthorized Access:

Inadequate access controls could allow an unauthorized user to access restricted information or perform restricted operations. Common vulnerabilities include weak IIS Web access controls, including Web permissions and weak NTFS permissions.

Countermeasures To Help Prevent Unauthorized Access Include:
a) Configure secure Web permissions.
b) Lockdown files and folders with restricted NTFS permissions.
c) Use .NET Framework access control mechanisms within our ASP.NET applications, including URL authorization and principal permission demands.

Application Threats and Countermeasures:

A good way to analyse application level threats are to organize them by application vulnerability category. The various categories used in the subsequent sections of this module and throughout the guidance, together with the main threats to our application.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

A. Input Validation:

Input validation is a security issue if an attacker discovers that our application makes unfounded assumptions about the type, length, format, or range of input data. The attacker can then supply carefully crafted input that compromises our application.

When network and host level entry points are fully secured; the public interfaces exposed by our application become the only source of an attack. The input to our application is a means to both tests our system and a way to execute code on an attacker's behalf. Does our application blindly trust input?
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

If It Does, Our Application May Be Susceptible To The Following:

1. Buffer Overflows:
Buffer overflow vulnerabilities can lead to denial of service attacks or code injection. A denial of service attack causes a process crash. Code injection alters the program execution address to run an attacker's injected code. The following code fragment illustrates a common example of a buffer overflow vulnerability.
void SomeFunction( char *pszInput )
{
  char szBuffer[10];
  // Input is copied straight into the buffer when no type checking is performed
  strcpy(szBuffer, pszInput);
  . . .
}

Managed .NET code is not susceptible to this problem because array bounds are automatically checked whenever an array is accessed. This makes the threat of buffer overflow attacks on managed code much less of an issue. It is still a concern, however, especially where managed code calls unmanaged APIs or COM objects.

Countermeasures To Help Prevent Buffer Overflows Include:
a) Perform thorough input validation. This is the first line of defence against buffer overflows. Although a bug may exist in our application that permits expected input to reach beyond the bounds of a container, unexpected input will be the primary cause of this vulnerability. Constrain input by validating it for type, length, format and range.

b) When possible, limit our application's use of unmanaged code, and thoroughly inspect the unmanaged APIs to ensure that input is properly validated.

c) Inspect the managed code that calls the unmanaged API to ensure that only appropriate values can be passed as parameters to the unmanaged API.

d) Use the /GS flag to compile code developed with the Microsoft Visual C++® development system. The /GS flag causes the compiler to inject security checks into the compiled code. This is not a fail-proof solution or a replacement for our specific validation code; it does, however, protect our code from commonly known buffer overflow attacks.

2. Cross-Site Scripting:
An XSS attack can cause arbitrary code to run in a user's browser while the browser is connected to a trusted Web site. The attack targets our application's users and not the application itself, but it uses our application as the vehicle for the attack.

Because the script code is downloaded by the browser from a trusted site, the browser has no way of knowing that the code is not legitimate. Internet Explorer security zones provide no defence. Since the attacker's code has access to the cookies associated with the trusted site and is stored on the user's local computer, a user's authentication cookies are typically the target of attack.

Countermeasures To Prevent XSS Include:
a) Perform thorough input validation. Our applications must ensure that input from query strings, form fields, and cookies are valid for the application. Consider all user input as possibly malicious, and filter or sanitize for the context of the downstream code. Validate all input for known valid values and then reject all other input. Use regular expressions to validate input data received via HTML form fields, cookies, and query strings.

b) Use HTMLEncode and URLEncode functions to encode any output that includes user input. This converts the executable script into harmless HTML.

3. SQL Injection:
A SQL injection attack exploits vulnerabilities in input validation to run arbitrary commands in the database. It can occur when our application uses the input to construct dynamic SQL statements to access the database. It can also occur if our code uses stored procedures that are passed strings that contain unfiltered user input. Using the SQL injection attack, the attacker can execute arbitrary commands in the database. The issue is magnified if the application uses an over-privileged account to connect to the database. In this instance, it is possible to use the database server to run operating system commands and potentially compromise other servers, in addition to being able to retrieve, manipulate, and destroy data.

Countermeasures To Prevent SQL Injection Include:
a) Perform thorough input validation. Our application should validate its input before sending a request to the database.

b) Use parameterized stored procedures for database access to ensure that input strings are not treated as executable statements. If we cannot use stored procedures, use SQL parameters when we build SQL commands.

c) Use the least privileged accounts to connect to the database.

4. Canonicalization:
Different forms of input that resolve to the same standard name (the canonical name), is referred to as canonicalization. Code is particularly susceptible to canonicalization issues if it makes security decisions based on the name of a resource that is passed to the program as input. Files, paths, and URLs are resource types that are vulnerable to canonicalization because in each case there are many different ways to represent the same name. File names are also problematic. For example, a single file could be represented as:
c:\temp\somefile.dat
somefile.dat
c:\temp\subdir\..\somefile.dat
c:\  temp\   somefile.dat
..\somefile.dat

Ideally, our code does not accept input file names. If it does, the name should be converted to its canonical form before making security decisions, such as whether access should be granted or denied to the specified file.

Countermeasures To Address Canonicalization Issues Include:
a) Avoid input file names where possible and instead use absolute file paths that cannot be changed by the end-user.

b) Make sure that file names are well-formed (if we must accept file names as input) and validate them within the context of our application. For example, check that they are within our application's directory hierarchy.

c) Ensure that the character encoding is set correctly to limit how input can be represented. Check that our application's Web.config has set the requestEncoding and responseEncoding attributes on the <globalization> element.

B. Authentication:

Depending on our requirements, there are several available authentication mechanisms to choose from. If they are not correctly chosen and implemented, the authentication mechanism can expose vulnerabilities that attacker can exploit to gain access to our system.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

The Top Threats That Exploit Authentication Vulnerabilities Include:

1. Network Eavesdropping:
If authentication credentials are passed in plaintext from client to server, an attacker armed with rudimentary network monitoring software on a host on the same network can capture traffic and obtain the user names and passwords.

Countermeasures To Prevent Network Eavesdropping Include:
a) Use authentication mechanisms that do not transmit the password over the network such as Kerberos protocol or Windows authentication.

b) Make sure passwords are encrypted (if we transmit passwords over the network) or use an encrypted communication channel, for example with SSL.

2. Brute Force Attacks:
Brute force attacks rely on computational power to crack hashed passwords or other secrets secured with hashing and encryption. To mitigate the risk, use strong passwords.

3. Dictionary Attacks:
This attack is used to obtain passwords. Most password systems do not store plaintext passwords or encrypted passwords. They avoid encrypted passwords because a compromised key leads to the compromise of all passwords in the data store. Lost keys mean that all passwords are invalidated.

Most user store implementations hold password hashes (or digests). Users are authenticated by re-computing hash based on the user-supplied password value and comparing it against the hash value stored in the database. If an attacker manages to obtain the list of hashed passwords, a brute force attack can be used to crack the password hashes.

With the dictionary attack, an attacker uses a program to iterate through all of the words in a dictionary (or multiple dictionaries in different languages) and computes the hash for each word. The resultant hash is compared with the value in the data store. Weak passwords such as "Yankees" (a favourite team) or "Mustang" (a favourite car) will be cracked quickly. Stronger passwords such as "?We'LlNevaFiNdMeyePasSWerd!", are less likely to be cracked.

Note: Once the attacker has obtained the list of password hashes, the dictionary attack can be performed offline and does not require interaction with the application.

Countermeasures To Prevent Dictionary Attacks Include:
a) Use strong passwords that are complex, are not regular words, and contain a mixture of upper case, lower case, numeric, and special characters.

b) Store non-reversible password hashes in the user store. Also, combine a salt value (a cryptographically strong random number) with the password hash.

4. Cookie Replay Attacks:
With this type of attack, the attacker captures the user's authentication cookie using monitoring software and replays it to the application to gain access under a false identity.

Countermeasures To Prevent Cookie Replay Include:
a) Use an encrypted communication channel provided by SSL whenever an authentication cookie is transmitted.

b) Use a cookie timeout to a value that forces authentication after a relatively short time interval. Although this doesn't prevent replay attacks, it reduces the time interval in which the attacker can replay a request without being forced to re-authenticate because the session has timed out.

5. Credential Theft:
If our application implements its own user store containing user account names and passwords, compare its security to the credential stores provided by the platform, for example, a Microsoft Active Directory® directory service or Security Accounts Manager (SAM) user store. Browser history and cache also store user login information for future use. If the terminal is accessed by someone other than the user who logged on, and the same page is hit, the saved login will be available.

Countermeasures To Help Prevent Credential Theft Include:
a) Use and enforce strong passwords.

b) Store password verifiers in the form of one way hashes with added salt.

c) Enforce account lockout for end-user accounts after a set number of retry attempts.

d) To counter the possibility of the browser cache allowing login access, create functionality that either allows the user to choose to not save credentials, or force this functionality as a default policy.

C. Authorization:

Based on user identity and role membership, authorization to a particular resource or service is either allowed or denied.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Top Threats That Exploit Authorization Vulnerabilities Include:

1. Elevation of Privilege:
When we design an authorization model, we must consider the threat of an attacker trying to elevate privileges to a powerful account such as a member of the local administrators group or the local system account. By doing this, the attacker can take complete control over the application and local machine. For example, with classic ASP programming, calling the RevertToSelf API from a component might cause the executing thread to run as the local system account with the most power and privileges on the local machine.

The main countermeasure that we can use to prevent elevation of privilege is to use the least privileged process, service, and user accounts.

2. Disclosure of Confidential Data:
The disclosure of confidential data can occur if sensitive data can be viewed by unauthorized users. Confidential data includes application-specific data such as credit card numbers, employee details, financial records and so on together with application configuration data such as service account credentials and database connection strings. To prevent the disclosure of confidential data we should secure it in persistent stores such as databases and configuration files, and during transit over the network. Only authenticated and authorized users should be able to access the data that is specific to them. Access to system-level configuration data should be restricted to administrators.

Countermeasures To Prevent Disclosure Of Confidential Data Include:
a) Perform role checks before allowing access to the operations that could potentially reveal sensitive data.

b) Use strong ACLs to secure Windows resources.

c) Use standard encryption to store sensitive data in configuration files and databases.

3. Data Tampering:
Data tampering refers to the unauthorized modification of data.

Countermeasures To Prevent Data Tampering Include:
a) Use strong access controls to protect data in persistent stores to ensure that only authorized users can access and modify the data.

b) Use role-based security to differentiate between users who can view data and users who can modify data.

4. Luring Attacks:
A luring attack occurs when an entity with few privileges can have an entity with more privileges performs an action on its behalf.

To counter the threat, we must restrict access to trusted code with the appropriate authorization. Using .NET Framework code access security helps in this respect by authorizing calling code whenever a secure resource is accessed or a privileged operation is performed.

D. Configuration Management:

Many applications support configuration management interfaces and functionality to allow operators and administrators to change configuration parameters, update Web site content, and to perform routine maintenance.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Top Configuration Management Threats Include:

1. Unauthorized Access to Administration Interfaces:
Administration interfaces are often provided through additional Web pages or separate Web applications that allow administrators, operators, and content developers to managed site content and configuration. Administration interfaces such as these should be available only to restricted and authorized users. Malicious users able to access a configuration management function can potentially deface the Web site, access downstream systems and databases or take the application out of action altogether by corrupting configuration data.

Countermeasures To Prevent Unauthorized Access To Administration Interfaces Include:
a) Minimize the number of administration interfaces.

b) Use strong authentication, for example, by using certificates.

c) Use strong authorization with multiple gatekeepers.

d) Consider supporting only local administration. If remote administration is absolutely essential, use encrypted channels, for example, with VPN technology or SSL, because of the sensitive nature of the data passed over administrative interfaces. To further reduce risk, also consider using IPSec policies to limit remote administration to computers on the internal network.

2. Unauthorized Access to Configuration Stores:
Because of the sensitive nature of the data maintained in configuration stores, we should ensure that the stores are adequately secured.

Countermeasures To Protect Configuration Stores Include:
a) Configure restricted ACLs on text-based configuration files such as Machine.config and Web.config.

b) Keep custom configuration stores outside of the Webspace. This removes the potential to download Web server configurations to exploit their vulnerabilities.

3. Retrieval of Plaintext Configuration Secrets:
Restricting access to the configuration store is a must. As an important defence in depth mechanism, we should encrypt sensitive data such as passwords and connection strings. This helps prevent external attackers from obtaining sensitive configuration data. It also prevents rogue administrators and internal employees from obtaining sensitive details such as database connection strings and account credentials that might allow them to gain access to other systems.

4. Lack of Individual Accountability:
Lack of auditing and logging of changes made to configuration information threatens the ability to identify when changes were made and who made those changes. When a breaking change is made either by an honest operator error or by a malicious change to grant privileged access, action must first be taken to correct the change. Then apply preventive measures to prevent breaking changes to be introduced in the same manner.

Keep in mind that auditing and logging can be circumvented by a shared account; this applies to both administrative and user/application/service accounts. Administrative accounts must not be shared. User/application/service accounts must be assigned at a level that allows the identification of a single source of access using the account, and that contains any damage to the privileges granted that account.

5. Over-privileged Application and Service Accounts:
If application and service accounts are granted access to change configuration information on the system, they may be manipulated to do so by an attacker. The risk of this threat can be mitigated by adopting a policy of using least privileged service and application accounts. Be wary of granting accounts the ability to modify their own configuration information unless explicitly required by design.

E. Sensitive Data:

Sensitive data is subject to a variety of threats. Attacks that attempt to view or modify sensitive data can target persistent data stores and networks.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Top Threats To Sensitive Data Include:

1. Access to Sensitive Data in Storage:
We must secure sensitive data in storage to prevent a user maliciously or otherwise from gaining access to and reading the data.

Countermeasures To Protect Sensitive Data In Storage Include:
a) Use restricted ACLs on the persistent data stores that contain sensitive data.

b) Store encrypted data.

c) Use identity and role-based authorization to ensure that only the user or users with the appropriate level of authority are allowed access to sensitive data. Use role-based security to differentiate between users who can view data and users who can modify data.

2. Network Eavesdropping:
The HTTP data for Web application travels across networks in plaintext and is subject to network eavesdropping attacks, where an attacker uses network monitoring software to capture and potentially modify sensitive data.

Countermeasures To Prevent Network Eavesdropping And To Provide Privacy Include:
a) Encrypt the data.
b) Use an encrypted communication channel, for example, SSL.

3. Data Tampering:
Data tampering refers to the unauthorized modification of data, often as it is passed over the network.

One countermeasure to prevent data tampering is to protect sensitive data passed across the network with tamper-resistant protocols such as hashed message authentication codes (HMACs).

F. Session Management:

Session management for Web applications is an application layer responsibility. Session security is critical to the overall security of the application.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Top Session Management Threats Include:

1. Session Hijacking:
A session hijacking attack occurs when an attacker uses network monitoring software to capture the authentication token (often a cookie) used to represent a user's session with an application. With the captured cookie, the attacker can spoof the user's session and gain access to the application. The attacker has the same level of privileges as the legitimate user.

Countermeasures To Prevent Session Hijacking Include:
a) Use SSL to create a secure communication channel and only pass the authentication cookie over an HTTPS connection.

b) Implement logout functionality to allow a user to end a session that forces authentication if another session is started.

c) Make sure we limit the expiration period on the session cookie if we do not use SSL. Although this does not prevent session hijacking, it reduces the time window available to the attacker.

2. Session Replay:
Session replay occurs when a user's session token is intercepted and submitted by an attacker to bypass the authentication mechanism. For example, if the session token is in plaintext in a cookie or URL, an attacker can sniff it. The attacker then posts a request using the hijacked session token.

Countermeasures To Help Address The Threat Of Session Replay Include:
a) Re-authenticate when performing critical functions. For example, before performing a monetary transfer in a banking application, make the user supply the account password again.

b) Expire sessions appropriately, including all cookies and session tokens.

c) Create a "do not remember me" option to allow no session data to be stored on the client.

3. Man in the Middle Attacks:
A man in the middle attack occurs when the attacker intercepts messages sent between us and our intended recipient. The attacker then changes our message and sends it to the original recipient. The recipient receives the message, sees that it came from us, and acts on it. When the recipient sends a message back to us, the attacker intercepts it, alters it, and returns it to us. We and our recipient never know that we have been attacked.

Any network request involving client-server communication, including Web requests, Distributed Component Object Model (DCOM) requests and calls to remote components and Web services are subject to man in the middle attacks.

Countermeasures To Prevent Man In The Middle Attacks Include:
a) Use cryptography. If we encrypt the data before transmitting it, the attacker can still intercept it but cannot read it or alter it. If the attacker cannot read it, he or she cannot know which parts to alter. If the attacker blindly modifies our encrypted message, then the original recipient is unable to successfully decrypt it and, as a result, knows that it has been tampered with.

b) Use Hashed Message Authentication Codes (HMACs). If an attacker alters the message, the recalculation of the HMAC at the recipient fails and the data can be rejected as invalid.

G. Cryptography:

Most applications use cryptography to protect data and to ensure it remains private and unaltered.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Top Threats Surrounding Our Application's Use Of Cryptography Include:

1. Poor Key Generation or Key Management:
Attackers can decrypt encrypted data if they have access to the encryption key or can derive the encryption key. Attackers can discover a key if keys are managed poorly or if they were generated in a non-random fashion.

Countermeasures To Address The Threat Of Poor Key Generation And Key Management Include:
a) Use built-in encryption routines that include secure key management. Data Protection Application Programming Interface (DPAPI) is an example of an encryption service provided on Windows 2000 and later operating systems where the operating system manages the key.

b) Use the strong random key generation functions and stores the key in a restricted location, for example, in a registry key secured with a restricted ACL, if we use an encryption mechanism that requires us to generate or manage the key.

c) Encrypt the encryption key using DPAPI for added security.

d) Expire keys regularly.

2. Weak or Custom Encryption:
An encryption algorithm provides no security if the encryption is cracked or is vulnerable to brute force cracking. Custom algorithms are particularly vulnerable if they have not been tested. Instead, use published, well-known encryption algorithms that have withstood years of rigorous attacks and scrutiny.

Countermeasures That Address The Vulnerabilities Of Weak Or Custom Encryption Include:
a) Do not develop own custom algorithms.

b) Use the proven cryptographic services provided by the platform.

c) Stay informed about cracked algorithms and the techniques used to crack them.

3. Checksum Spoofing:
Do not rely on hashes to provide data integrity for messages sent over networks. Hashes such as Safe Hash Algorithm (SHA1) and Message Digest compression algorithm (MD5) can be intercepted and changed. Consider the following base 64 encoding UTF-8 messages with an appended Message Authentication Code (MAC).

To counter this attack, use a MAC or HMAC. The Message Authentication Code Triple Data Encryption Standard (MACTripleDES) algorithm computes a MAC, and HMACSHA1 computes an HMAC. Both use a key to produce a checksum. With these algorithms, an attacker needs to know the key to generate a checksum that would compute correctly at the receiver.

H. Parameter Manipulation:

Parameter manipulation attacks are a class of attack that relies on the modification of the parameter data sent between the client and Web application. This includes query strings, form fields, cookies, and HTTP headers.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Top Parameter Manipulation Threats Include:

1. Query String Manipulation:
Users can easily manipulate the query string values passed by HTTP GET from client to server because they are displayed in the browser's URL address bar. If our application relies on the query string values to make security decisions, or if the values represent sensitive data such as monetary amounts, the application is vulnerable to attack.

Countermeasures To Address The Threat Of Query String Manipulation Include:
a) Avoid using a query string parameters that contain sensitive data or data that can influence the security logic on the server. Instead, use a session identifier to identify the client and store sensitive items in the session store on the server.

b) Choose HTTP POST instead of GET to submit forms.

c) Encrypt query string parameters.

2. Form Field Manipulation:
The values of HTML form fields are sent in plaintext to the server using the HTTP POST protocol. This may include visible and hidden form fields. Form fields of any type can be easily modified and client-side validation routines bypassed. As a result, applications that rely on form field input values to make security decisions on the server is vulnerable to attack.

To counter the threat of form field manipulation, instead of using hidden form fields, use session identifiers to reference state maintained in the state store on the server.

3. Cookie Manipulation:
Cookies are susceptible to modification by the client. This is true of both persistent and memory-resident cookies. Several tools are available to help an attacker modify the contents of a memory-resident cookie. Cookie manipulation is the attack that refers to the modification of a cookie, usually to gain unauthorized access to a Web site.

While SSL protects cookies over the network, it does not prevent them from being modified on the client computer. To counter the threat of cookie manipulation, encrypt or use an HMAC with the cookie.

4. HTTP Header Manipulation:
HTTP headers pass information between the client and the server. The client constructs request headers while the server constructs response headers. If our application relies on request headers to make a decision, our application is vulnerable to attack.

Do not base security decisions on HTTP headers. For example, do not trust the HTTP Referrer to determine where a client came from because this is easily falsified.

I. Exception Management:

Exceptions that are allowed to propagate to the client can reveal internal implementation details that make no sense to the end-user but are useful to attackers. Applications that do not use exception handling or implement it poorly are also subject to denial of service attacks.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Top Exception Handling Threats Include:

1. Attacker Reveals Implementation Details:
One of the important features of the .NET Framework is that it provides rich invaluable exception details to developers. If the same information is allowed to fall into the hands of an attacker, it can greatly help the attacker exploit potential vulnerabilities and plan future attacks. The type of information that could be returned includes platform versions, server names, SQL command strings, and database connection strings.

Countermeasures To Help Prevent Internal Implementation Details From Being Revealed To The Client Include:
a) Use exception handling throughout our application's codebase.

b) Handle and log exceptions that are allowed to propagate to the application boundary.

c) Return generic, harmless error messages to the client.

2. Denial of Service:
Attackers will probe a Web application, usually bypassing deliberately malformed input. They often have two goals in mind. The first is to cause exceptions that reveal useful information and the second is to crash the Web application process. This can occur if exceptions are not properly caught and handled.

Countermeasures To Help Prevent Application-Level Denial Of Service Include:
a)  Thoroughly validate all input data at the server.

b) Use exception handling throughout our application's codebase.

J. Auditing and Logging:

Auditing and logging should be used to help detect suspicious activity such as footprinting or possible password cracking attempts before an exploit actually occurs. It can also help deal with the threat of repudiation. It is much harder for a user to deny performing an operation if a series of synchronized log entries on multiple servers indicate that the user performed that transaction.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

Top Auditing And Logging Related Threats Include:

1. User Denies Performing an Operation:
The issue of repudiation is concerned with a user denying that he or she performed an action or initiated a transaction. We need defence mechanisms in place to ensure that all user activity can be tracked and recorded.

Countermeasures To Help Prevent Repudiation Threats Include:
a) Audit and log activity on the Web server and database server, and on the application server as well, if we use one.

b) Log key events such as transactions and login and logout events.

c) Do not use shared accounts since the original source cannot be determined.

2. Attackers Exploit an Application Without Leaving a Trace:
System and application-level auditing is required to ensure that suspicious activity does not go undetected.

Countermeasures To Detect Suspicious Activity Include:
a) Log critical application level operations.

b) Use platform-level auditing to audit login and logout events, access to the file system, and failed object access attempts.

c) Back up log files and regularly analyse them for signs of suspicious activity.

3. Attackers Cover Their Tracks:
Our log files must be well-protected to ensure that attackers are not able to cover their tracks.

Countermeasures To Help Prevent Attackers From Covering Their Tracks Include:
a) Secure log files by using restricted ACLs.

b) Relocate system log files away from their default locations.

Design Guidelines for Secure Web Applications:

The Architecture of Web Applications:

Web application architecture is a framework which maintains interactions between application components. First of all, we need to clarify what is the web application to understand the basics of web application architecture. In short, it is a client-server app, including middleware systems, user interfaces, and databases. Web application combines both server-side and client-side scripts. The server-side scripts are responsible for the storage of the data, while the client-side present the data to customers. Generally, it is the channel for data exchange.

There are different web application architecture patterns that allow covering various criteria for high-performance cloud-based solutions. We should take into account the requirements of the user, the developer, and software product owner.

User’s requirements generally concentrated on usability. It includes time used for updating information on pages, ability to switch between pages or save links and bookmarks and options for offline work.

Developer’s requirements mainly concentrated on performance, scalability and development speed. Developers are the ones who introduce new features, restructure the code and parallelize the software development process, they might also minimize the server’s response time, increase computation power, provide consistent and available data.

Software product owner covers its functioning (hardware, maintenance, network infrastructure) and security (any business or user’s information data has to be kept secure).
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp
Fig:How Web Application Works?

Components of Web Applications Architectures:

Web application architectures are comprised of several components that help build its digital makeup. These components can be categorized into two areas: user interface app components and structural components.

User interface app components refer to the web pages displaying dashboards, logs, notifications, configuration settings, and more. They are not relevant to the structural development of the application and are more user interface/experience-oriented.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

The structural components, which are the real meat of the app development process, are:
a) The web browser or client.
b) The web application server.
c)  The database server.

The web browser or client is the interface rendition of a web app functionality, with which the user interacts with. This content delivered to the client can be developed using HTML, JavaScript, and CSS and doesn’t require operating system related adaptations. In essence, the web browser or client manages how end-users interact with the application.

The web application server manages business logic and data persistence and can be built using PHP, Python, Java, Ruby, .NET, Node.js, among other languages. It’s comprised of at least a centralized hub or control centre to support multi-layer applications.

The database server provides and stores relevant data for the application. Additionally, it may also supply the business logic and other information that is managed by the web application server.

Types of Web Application Architecture:

There are three, well-known Web Application Architecture types available in the modern tech landscape.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

1. Single Page Applications (SPA):

Modern, efficient applications are designed to only request the most necessary elements of content and information to generate an intuitive and interactive user experience. Single page web applications interact with the user in a more dynamic fashion by providing updated content within the current page, rather than loading entirely new pages from the server with each action from the user. This helps prevent interruptions in the user experience, transforming the behaviour of the application such that it resembles a traditional desktop application. The most heavyweight player is AJAX, short for Asynchronous JavaScript and XML, which is the foundation for page communications making SPAs possible.  

2. Microservices:

Microservices are small, lightweight services that execute a specific, single functionality. The Microservices Architecture framework offers a comprehensive set of advantages that help developers be more productive and speed up the deployment process of bespoke software applications. Since the components in the application is not directly dependent on each other they do not need to be developed in the same coding language; developers have free range to work with the technology stack of their choice that works best for the needs of the service and in the desired timeframe.

3. Serverless Architectures:

This approach leverages third-party cloud infrastructure services to outsource server and infrastructure management allowing applications to execute required or custom logic without concerning themselves with the infrastructure related tasks While it is somewhat similar to Microservices, the development entity does not own or manage the backend servers, which makes it simpler when the development company does not want to manage or support the servers and the hardware they run in.

Design Issues of Web Application:

Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp

1. User Interface and User Experience:

Think a decade ago, the web was a completely different place. Smartphones don’t exist. The simpler and customer-oriented web application is highly expected now. Sometimes it’s the small UI elements that make the biggest impact. In the era of Smartphones, websites should be responsive enough on smaller screens. If our web applications frustrate or confuse users, then it is difficult to maintain our customer’s loyalty to our website. Website navigation is another part often neglected by developers. Intuitive navigation creates a better user experience for the website visitor. Intuitive navigation is leading our audience to the information they are looking without a learning curve. And when the navigation is intuitive, visitors can find out information without any pain, creating a flawless experience preventing them from visiting the competitors.

2. Scalability:

Scalability is neither performance nor it’s about making good use of computing power and bandwidth. It’s about load balancing between the servers, hence, when the load increases (i.e. more traffic on the page) additional servers can be added to balance it. We should not just throw all the load on a single server but we should design the software such that it can work on a cluster of servers. Service-oriented architecture (SOA) can help in improving scalability when more and more servers are added. SOA gives us the flexibility to change easily. A service-oriented architecture is a design where application components provide services to other components through the communication protocol, basically over a network.

3. Performance:

Generally, it is accepted that website speed has major importance for a successful website. When our business is online every second count. Slow web applications are a failure. As a result, customers abscond our website thus, damaging our revenue as well as reputation. It is said that think about performance first before developing the web application. Some of the performance issues are poorly written code, Un-Optimized Databases, Unmanaged Growth of data, Traffic spikes, Poor load distribution, Default configuration, troublesome third-party services, etc. A Content Distribution Network (CDN) is a globally distributed network of proxy servers deployed in multiple data centres. It means instead of using a single web server for the website, use a network of servers. Some of the benefits of CDN are that the requests on the server will be routed to different servers balancing the traffic, the files are divided on different CDNs so there will be no queuing and wait for downloading different files like images, videos, text, etc.

4. Knowledge of Framework and Platforms:

Frameworks are the kick start for development languages: they boost performance, offer libraries of coding and extend capabilities, so developers need not do hand-coding web applications from the ground up. Frameworks offer features like models, APIs, snippets of code and other elements to develop dynamic web applications. Some of the frameworks have a rigid approach to development and some are flexible. Common examples of web frameworks are PHP, ASP.Net, Ruby on Rails and J2EE. Web platforms provide client libraries to build on existing frameworks required to develop a web application or website. New functionality can be added via external API. Developers and small business owners should have a clear understanding of their company needs related to website and application development. Information delivery and online presence would require a simple web platform such as WordPress or Squarespace but a selling product requires an e-commerce platform such as Magento, Shopify. WooCommerce or BigCommerce). While choosing the perfect platform one should also consider technical skills, learning curve, pricing, customization options and analytics.

5. Security:

In the midst of design and user experience, web app security is often neglected. But security should be considered throughout the software development life cycle, especially when the application is dealing with the vital information such as payment details, contact information, and confidential data. There are many things to consider when it comes to web application security such as the denial of service attacks, the safety of user data, database malfunctioning, unauthorized access to restricted parts of the website, etc. Some of the security threats are Cross-Site Scripting, Phishing, Cross-Site Request Forgery, Shell Injection, Session Hijacking, SQL Injection, Buffer Overflow, etc. The website should be carefully coded to be safe against these security concerns.
Web development can be deliberately difficult as it involves achieving a final product which should be pleasing, builds the brand and is technically up to date with sound visuals.

Deployment Consideration:

Once we’ve built and tested our Meteor application, we need to put it online to show it to the world. Deploying a Meteor application is similar to deploying any other WebSocket-based Node.js app but is different in some of the specifics.
Security in Web Applications, Web application security fundamentals, Foundations of security, Security Threats, Web Security Vulnerabilities, Security Attacks, Security principles, Threats and countermeasures, Anatomy of attack, Network threats and countermeasures, Host threats and countermeasures, Application threats and countermeasures, Configuration managements, Design guidelines for secure web applications, Architecture and design issues for web applications, Deployment considerations, Input validations, Authentication, Authorization, Sensitive data, Session management, Cryptography, Parameter manipulation, Exception management, Auditing, Logging, owasp
Deploying a web application is fundamentally different from releasing most other kinds of software, in that we can deploy as often as we’d like to. We don’t need to wait for users to do something to get the new version of our software because the server will push it right at them.
However, it’s still important to test our changes thoroughly with a good process of Quality Assurance (QA). Although it’s easy to push out fixes to bugs, those bugs can still cause major problems to users and even potentially data corruption!

1. Never Use --production Flag To Deploy!

--production flag is purely meant to simulate production magnification but does almost nothing else. This still watches source code files, exchanges data with package server and does a lot more than just running the app, leading to unnecessary computing resource wasting and security issues. Please don’t use --production flag to deploy!

2. Deployment Environments:

In web application deployment it’s common to refer to three runtime environments:
a) Development: This refers to our machine where we develop new features and run local tests.

b) Staging: An intermediate environment that is similar to production, but not visible to users of the application. Can be used for testing and QA.

c) Production: The real deployment of our app that our customers are currently using.

The idea of the staging environment is to provide a non-user-visible test environment that is as close as possible to production in terms of infrastructure. It’s common for issues to appear with new code on the production infrastructure that doesn’t happen in a development environment. Very simple example issues that involve latency between the client and server, connecting to a local development server with tiny latencies, we just may never see such an issue.

For this reason, developers tend to try and get staging as close as possible to production. This means that all the steps we outline below about production deployment, should, if possible, also be followed for our staging server.

3. Environment Variables And Settings:

There are two main ways to configure our application outside of the code of the app itself:
a) Environment Variables: This is the set of ENV_VARS that are set on the running process.

b) Settings: These are in a JSON object set via either the --settings Meteor command-line flag or stringified into the METEOR_SETTINGS environment variable.

Settings should be used to set environment (i.e. staging vs. production) specific things, like the access token and secret used to connect to Google. These settings will not change between any given processes running our application in the given environment.

Environment variables are used to set process-specific things, which could conceivably change for different instances of our application’s processes.

A final note on storing these settings: It’s not a good idea to store settings the same repository where we keep our app code.

4. Other Considerations:

There are some other considerations that we should make before we deploy our application to a production host. Remember that we should if possible do these steps for both our production and staging environments.

a. Domain Name:
What URL will users use to access our site? We’ll probably need to register a domain name with a domain registrar, and setup DNS entries to point to the site (this will depend on how we deploy). If we deploy to Galaxy, we can use a x.meteorapp.com or x.eu.meteorapp.com domain while we are testing the app. 

b. SSL Certificate:
It’s always a good idea to use SSL for Meteor applications. Once we have a registered domain name, we’ll need to generate an SSL certificate with a certificate authority for our domain. If we deploy to Galaxy, we can generate a free SSL certificate with a single click.

c. CDN:
It’s not strictly required, but often a good idea to set up a Content Delivery Network (CDN) for our site. A CDN is a network of servers that hosts the static assets of our site (such as JavaScript, CSS, and images) in numerous locations around the world and use the server closest to our user to provide those files to speed up their delivery. For example, if the actual web server for our application is on the east coast of the USA and our user is in Australia, a CDN could host a copy of the JavaScript of the site within Australia or even in the city the user is in. This has huge benefits for the initial loading time of our site.

No comments:

Post a Comment

If you have any doubt, then don't hesitate to drop comments.