CodeStack

Most modern applications require individuals to verify their identity. Authentication is the process of verifying the identity of an individual. A user can interact with a web application using multiple actions. Access to certain actions or pages can be restricted using user levels. Authorization is the process of controlling user access via assigned roles & privileges

Authentication

Authentication is the confirmation by some means that a user is who claims to be. There is also a method using a client certificate (an electronic certificate issued to authenticate an individual or organization ), but the most common method for web applications is form authentication, in which an ID and password are entered in a form. As a point when performing form authentication：

  • Try to increase the strength of your password
  • Account lock in case of repeated password mistakes
  • How passwords, encryption keys are stored
  • Adopt secure implementations when maintaining login state
  • Adoption of two-factor authentication in combination with authentication other than ID/password

Authorization

Authorization is the granting of rights to authenticated users. Since the screens, items, and data ranges that can be viewed change depending on the authority, it is necessary to thoroughly check for the following mistakes that lead to vulnerabilities

  • If you hit the URL directly due to improper implementation of the authorization process, an unauthorized page will be displayed.
  • It is implemented in such a way that information outside the authority can be seen when the URL parameter is changed.
  • It is implemented so that the presence or absence of authority is controlled only by displaying / hiding the menu
  • Permission information is stored in hidden parameters and cookies
  • It is designed to create a user that indicates an administrator without using a role.

Input

You can’t expect your input to be correct and not malicious. so at least the following is required.

  • Validate character encoding and convert if necessary
  • Validation of input values and conversion processing if necessary

Character encoding is, simply determining which character/meaning is assigned to which code (encoding), and the combination has a name such as “UTF-8” or “ SJIS “.

If this is wrong, garbled characters or strange behavior will occur, so it is necessary to verify whether the input is the same as what the system expects, and convert it to the correct one if necessary.
Input validation is the process of testing input received by the application for compliance against a standard defined within the application. It can be as simple as strictly typing a parameter and as complex as using regular expressions or business logic to validate input.
There are two different types of input validation approaches:

  • Is the data retrieved from the database the same as the input data?
  • Have you eliminated anything that may cause incorrect behavior in subsequent processing?

Database Access

SQL Language is often used for database access, and it is necessary to pay attention to the vulnerability SQL injection that accompanies it.
For example, by passing a character string such as “” OR ‘1’ = ‘1’” entered in the password to SQL as it is, the condition is always satisfied (you can log in without knowing the password). As in the example, malicious strings entered in inputs and parameters cause SQL to malfunction. An approach to prevent that as the following.

  1. Ensure that SQL statements are constructed using placeholders (embedding ? in place of variable variables and expressions)
  2. Prevent SQL from being changed by converting characters that are interpreted as SQL syntax (for example, “’”, “<”, “>”, “=”, “(“, “}”, etc.) to harmless characters .

OS Command Injection

OS command injection (also known as shell injection) is a web security vulnerability that allows an attacker to execute arbitrary operating system (OS) commands on the server that is running an application, and typically fully compromise the application and all its data. Frequently, An attacker can leverage an OS command injection vulnerability to compromise other parts of the hosting infrastructure, exploiting trust relationships to pivot the attack to other systems within the organization.
What is the possibility that you can do it with os command injection?

  • The implementation uses a function that has the ability to call the shell (OS command)
  • Passing parameters to that function and running it
  • Insufficient sanitization of characters (metacharacters) that have meaning in the shell in that parameter Since three possibilities are explained, you can prevent it as the follows.
  • Avoid using functions that call shell (OS commands) as much as possible
  • Do not pass externally input strings to command line parameters.
  • Prevent metacharacters in the string of parameters to be passed

Directory Traversal

Directory traversal (also known as file path traversal) is a web security vulnerability that allows an attacker to read arbitrary files on the server that is running an application. This might include application code and data, credentials for back-end systems, and sensitive operating system files. In some cases, an attacker might be able to write to arbitrary files on the server, allowing them to modify application data or behavior, and ultimately take full control of the server.

There are two possibilities. One is that you can see files that you don’t intend to make public.

  • Forgetting to disable directory
  • A file is placed in a public folder, and the file can be browsed by specifying the URL.
  • Inadvertently including information such as file path names in error messages, etc.
  • You do not have access permissions for files that you do not want to make public

These are caused by some kind of mistake, so the only way to prevent them is to keep basic things in mind at the design stage, such as putting files you don’t want to make public in a private directory

And the other is a vulnerability in a function called directory.
What causes this vulnerability?

  • It is a specification / implementation that can specify the file name from the outside
  • The implementation allows you to specify different directories as file names .
  • Not checking the access permission for the assembled file name It will be considered. So, in order to prevent the vulnerabilities, we should do it as the following.
  • Specifications and implementations that allow file names to be specified externally will not be implemented.
  • Implement so that the file name does not include the directory name.
  • Be sure to check the accessibility of the constructed file name but furthermore
  • Limit the file name to alphanumeric characters

Irreversible processing

An irreversible process is as the following,

  • Credit card payment
  • Remittance from the user’s account
  • Change password or email address

If you unintentionally execute these from a web application, it will be irreversible, so it is extremely important not to create the vulnerabilities that occur here.
Typical of this vulnerability are “cross-site request forgery ( CSRF )” and “clickjacking”.
CSRF is a vulnerability that “passes through confirmation that the request and executes an irreversible process from the web application” .
CSRF has the following properties specific to web applications:

  • Any domain URL can be specified in the action attribute of the form element
  • The session ID stored in the cookie is automatically sent to the target site

So, if you pay attention to the implementation, it will work out. The countermeasure is to “ recognise the pages that need CSR countermeasures and make sure that the page is the request intended by the user”.
There is a typical way to verify a request

  1. Embedded secret information ( token that can be confirmed as a user’s intended request
  2. Prompt for re-entry of password before executing the process
  3. Check the Referer to confirm that the request

Step 2 “Re-enter password” increases the user’s time and effort, so the situation where it can be used is limited . we can’t use it.

Therefore, inevitably, Step 1 “ token embedding” is said to be the easiest to use.

Fortunately, most CSRF countermeasures are prepared as mechanisms at the language level, so don’t forget to use them appropriately.
Clickjacking ``By overlaying the target site on top of the trap site and making the attack target form transparent, the user thinks that they have clicked a harmless button on the trap site, but the attack target is actually dangerous. It is a vulnerability that makes you click the button .
HTML features (iframe elements and CSS z-index, etc.) are cleverly abused.
This is difficult to deal with by the web application itself, if the own web application is displayed in an “iframe”.
Therefore, specifying DENY in the “ X-Frame-Options “ (response) header to prevent it from being displayed inside iframes is a way to prevent this vulnerability .
Also, as a security measure, it is better to have a method of “ sending a notification e-mail to the registered e-mail address so that the user can easily notice it” after executing the process that cannot be undone.
Recently, there are more and more sites that send you emails when you change your password or other important information, or when you log in with a different device than usual.

XSS

Cross-site Scripting (XSS) is a client-side code injection attack. The attacker aims to execute malicious scripts in a web browser of the victim by including malicious code in a legitimate web page or web application. The actual attack occurs when the victim visits the web page or web application that executes the malicious code. The web page or web application becomes a vehicle to deliver the malicious script to the user’s browser. Vulnerable vehicles that are commonly used for Cross-site Scripting attacks are forums, message boards, and web pages that allow comments.

There are two stages to a typical XSS attack:

  • To run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject malicious code (payload) into a web page that the victim visits.
  • After that, the victim must visit the web page with the malicious code. If the attack is directed at particular victims, the attacker can use social engineering and/or phishing to send a malicious URL to the victim.

For step one to be possible, the vulnerable website needs to directly include user input in its pages. An attacker can then insert a malicious string that will be used within the web page and treated as source code by the victim’s browser. There are also variants of XSS attacks where the attacker lures the user to visit a URL using social engineering and the payload is part of the link that the user clicks.

The following is a snippet of server-side pseudocode that is used to display the most recent comment on a web page:

print "<html>"
print "<h1>Most recent comment</h1>"
print database.latestComment
print "</html>"

The above script simply takes the latest comment from a database and includes it in an HTML page. It assumes that the comment printed out consists of only text and contains no HTML tags or other code. It is vulnerable to XSS, because an attacker could submit a comment that contains a malicious payload, for example:

<script>doSomethingEvil();</script>

The web server provides the following HTML code to users that visit this web page:

<html>
    <h1>Most recent comment</h1>
    <script>doSomethingEvil();</script>
</html>

When the page loads in the victim’s browser, the attacker’s malicious script executes. Most often, the victim does not realize it and is unable to prevent such an attack.