HOST HEADER INJECTION

HOST HEADER INJECTION

Most of the common web servers are configured in the form of the same server to host many web applications with the same IP address this type of configuration is the reason for the Host Header issues. Here we are going to deal with the host header injection attack in various forms, its impact and mitigation.

CONTENTS:

1. HOST HEADER ISSUES
2. RISK
3. HOW ATTACKERS UTILIZE HOST HEADER ATTACK
4. WHY HOST HEADER HAPPEN
5. HOW TO FIND HOST HEADER ISSUES
6. PHASES OF HOST HEADER ISSUES
7. IMPACT OF HOST HEADER ISSUES
8. MITIGATIONS FOR HOST HEADER ATTACK
9. CONCLUSION

HOST HEADER ISSUES:

An attacker can manually divert the code to produce the hacker desired output simply by editing the host header. Most probably web servers are configured to pass the host header to the first virtual host in the list without proper reorganisation, So It is possible to send the HTTP requests with arbitrary host headers to the first virtual host. In that case, if we specify an invalid Host means the web server process it and pass the invalid host header to the first virtual host in the list.

An attacker can modify the host name by giving a fake web page or a vulnerable website and deliver it to the user and fraud the users.

Example:

The result will redirect the user to the attacker’s website by simply modifying the host header

RISK:

Most probably many websites use the values provided in the user input field and uses it afterwards without an improper input validation. Commonly this will not have that much impact on the application, but in some cases, if the application accepts the host header, the risk lays there. There may occur,

• URL redirection problems.
• Username and password credentials may be theft.
• Financial loss may happen in Finance sectors.

HOW ATTACKERS UTILIZE HOST HEADER ATTACK:

The exploitation is based on the logic of the web application. If the application does not use the user input value, then there is no risk. But the host header attack is considered as a serious issue at the time of resetting our password. When we are resetting our forgotten password, or we change our password for our privacy, the web application generates a link dynamically there it uses the host header provided in the request. In this scenario, the hacker uses this header for their evil cause. The hackers use some social engineering and phishing attacks for getting the link. So, the developer should realise the importance of the host header attack.

WHY HOST HEADER HAPPEN:

It is an injection type of attack that done on the HTTP headers.

• HTTP headers are dynamically generated based on the input of the user. User inputs can be edited or spoof by attackers. It is accessible by everyone.
• Any website that does not correctly validate or verify the HTTP Host headers.

HOW TO FIND HOST HEADER ISSUES:

Verify the header of the request. Inject other domain in the header field and check the response in the browser.

PHASES OF HOST HEADER ISSUES:

1. WEB CACHE POISONING WITH SINGLE HOST HEADER:

Web cache poisoning is a kind of technique used by a hacker to manipulate a web cache that serves a poisoned content for those who requests that webpage. For this attack, the hacker needs to poison a caching proxy run by the website itself, or content delivery networks (CND’s), or other caching mechanisms are carried out between the client and the server. In this scenario where caching is enabled, A hacker will potentially embed a remote URL as the base-URL for any website. This scenario then causes other users who request the site will be redirected unknowingly. Thus if an application fails to prevent the user from using the X-Forwarded-Host header, it will effectively override the Host header. The cache will serve the poisoned content to everyone those who request the webpage without the knowledge of the victim.

EXAMPLE:

 

2. X-FORWARDED HOST HEADER:

Host header injection is mitigated by preventing the tampering of Host header. It means if any request is made with tampered host header, the application responds with an error message like “404 Not Found”. Another way to pass arbitrary Host headers is to use the X-Forwarded-Host header. In some configurations, this header will rewrite the value of the Host header. Therefore it’s possible to make the following request.

EXAMPLE:

3. WEB POISONING WITH MULTIPLE HOST HEADERS:

It is one of the forms of web cache poisoning attack. It is similar to that of the web cache poisoning using the single header. The only difference is that in this type is that it use multiple headers more than one to the users those who request the website. By tampering with the header, it is possible. The web cache will deliver the wrong content to the user with their knowledge.

EXAMPLE:

GET / HTTP/1.1

Host: www.example.com

Host: www.evil.com

4. PASSWORD RESET POISONING:

 The significant impact of Host header attack lies in the password resetting functionality. The most common scenario of this attack the hacker generates a secret token and sends a mail that has a link that contains the mysterious symbol of the hacker. The hacker urges the user to make use of his link, and to requests, a password reset link which redirects the user to him. In this case, if the web application makes use of this host header value when composing with the reset link and when the user clicks the poisoned reset link in the mail, then the user will become a victim to the hacker. The attacker will obtain the password reset token and make use of his password for his destructive purposes.

EXAMPLE:

 

IMPACT OF HOST HEADER ISSUES:

1. A hacker can modify the legitimate host header with a wrong host in the request, and it poisons the cache of the web application server and the proxy. It has nothing to do with the browser. When the authorised user tries to access the host, but still the cache of the web server is poisoned with the hacker’s domain that redirects the licensed user to the domain of the hacker.
2. If the host headers are used for writing links without a proper HTML encoding, there may be a possibility for Cross-site
3. Access to the internal
4. HTML INJECTION also can be done.

MITIGATIONS FOR HOST HEADER ATTACK:

• Proper sanitation of input values.
• Proper verification of the request that it came from the original target host or not.
• Mitigate the Host header attack in Apache and Nginx by creating a dummy virtual host that catches all requests from unrecognised Host headers.
• Whitelist the trusted domains at the initial phase of the web application.
• Respective Mapping of the domains that received in the host header of each HTTP request with itself.
• Use secure server configuration.
• Disable the support for the X-Forwarded-Host header option.

CONCLUSION:

Many application developers did not realise that the HTTP host header is accessible and controlled by all user. In an application security perspective, the input given by the user is always deceivable, and it is unsafe to trust. So, a web developer should consider host header issues as a dangerous thing not to and neglect it; we should find the impacts caused by the host header and follow the mitigation to safeguard ourselves.

We Briskinfosec is Center for Cyber Security Excellence passionate to protect you from all application security threats on your budget. Talk to our experts contact@briskinfosec.com

AUTHOR

Alex Daniel Raj

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/alex-daniel-raj-xavier-b77869145/

SSRF (SERVER SIDE REQUEST FORGERY)

SSRF (SERVER SIDE REQUEST FORGERY)

INTRODUCTION

Server-Side Request Forgery (SSRF) refers to an attack wherein an attacker can send a crafted request from a vulnerable web application. SSRF is mainly used to target internal systems behind WAF (web application firewall) that are unreachable to an attacker from the external network. Additionally, it’s also possible for an attacker to mark SSRF to access services from the same server that is listening on the loopback interface address called (127.0.0.1).

Typically, Server Side Request Forgery (SSRF) occurs when a web application is making a request, where an attacker has full or partial control of the claim that is sent. A typical example is when an attacker can control all or part of the URL to which the web application makes a request to some third-party services, and here I have captured the parameter of file= URL, and I tried to perform this server-side forgery attack

tried to perform this server-side forgery attack

In the above figure, the perpetrator forges a request for a fund transfer website, and he embeds it into the visitor site. when the visitor logs the website for the transaction and clicks the perpetrator created a link, it redirects to Perpetrator site, and the amount is transferred to his account

SSRF IMPACTS:

By this attack, an attacker can gather information about ports, IP addresses, Remote code execution and it also discovers the IP addresses of servers running behind a reverse proxy etc.

For Example, I have tried SSRF attack on a testing site for your reference

Vulnerable site: http://testphp.vulnweb.com/

POC 1:

In Burp Suite I have checked for some different redirection parameter other than URL=, and in the search field I have tried with various parameters and using this parameter of file= and here I have captured the request of the particular path and sent it to the repeater

POC 2:

Request Captured from the search file in the repeater and here in file feed a .jpg file is available, now I removed the file and entered a third party URL on file Redirected URL: https://www.expressvpn

POC 3:

Once I click on Go to capture response the response is changed to expessvpn.com, and you can see the IP of the testphp.vulnweb.com, but in render page, you can see the expressvpn.com site gets loaded as follows.

POC 4:

PREVENTION FROM SSRF:

• Generic error messages should be displayed to every client as unhandled responses might end up revealing sensitive information or data leakage about the server when any other raw response or different parameter is used.
• URL schemas other than HTTP and HTTPS should be blacklisted. Instead, these two mentioned protocols should be whitelisted thereby not allowing different schemas which are not in use like file:///, direct://, feed://, touch://  and FTP:// which might prove to be dangerous for SSRF.

CONCLUSION:

Hence, the Server Side Request Forgery attack has been made from the server side and the required web page has been redirected to some other web pages and to prevent from such types of attacks allow only the particular subdomains of the required web page and whitelist the other web pages which they are not in use.

REFERENCE LINKS:

• https://dzone.com/articles/the-server-side-request-forgery-vulnerability-and
• https://medium.com/poka-techblog/server-side-request-forgery-ssrf-attacks-part-1-the-basics-a42ba5cc244a

AUTHOR

Ram Kumar

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/ram-kumar-3439b511a/

HTML INJECTION ATTACK

HTML INJECTION ATTACK

INTRODUCTION:

HTML injection is an attack which occurs in web applications that allows users to insert an HTML tag attributes via using any specific parameters like,  <h>, </h1>, <td>, <tr>, <a href> tags are used as one of the sources to perform this HTML based injection attack.

These strategies provided with untrusted input, at that point there is a high risk of XSS, specifically an HTML injection one. If strings not sanitised efficiently, the issue could prompt XSS based HTML injection. This HTML injection could lead the attacker to modify the web content easily.

POSSIBLE ATTACK SCENARIO:

In this way, how we can perform an HTML injection attack using the following steps,

•  In this beginning process, an attacker can find the injection flaw and try to make an HTML injection attack.
• Attacker crafts the malicious links, including his infected HTML injection code and sends it to a client through an email
• When the client visits the web page because of the page located within a trusted domain
• The attacker can inject an HTML code is rendered and presented to the client requesting valid credentials like username and password
• The client enters a username and password, which are both sent to the attacker server.

HTML injection attack also have two different types, there are

• stored HTML injection attack
• Reflected HTML injection attack

STORED HTML INJECTION ATTACK

In this stored HTML is also known as persistence (always stored in the backend database), the attacker can give the credentials inserting in the web server it can be stored in permanently, and the application server gives out it to the user when the user visits the targeted website. Here I have to give a sample HTML code for the stored HTML injection.

When the client clicks the payload, it gets redirected to the official part of the website; the injected HTML code will get executed by the browser.

REFLECTED HTML INJECTION

The reflected HTML is known as Non-persistence (It does not store in the backend database, it will get immediately indicated). Whenever the backend server processes any HTML input without proper sanitisation and validation of the given HTML input,  it will lead to HTML injection in the web application.

Here I have to give the input like <h>you are hacked</h>, and it will reflect as ‘you are hacked “ class=” colourbox” title=” help me with page”>

MITIGATION FOR HTML INJECTION:

Here we used parameterised queries to block unwanted scripts for the HTML injection using special characters like <, >, “, ‘, %, &, / to appropriately sanitised in the given input fields. The favoured choice is to utilise a protected API which stays away from the utilisation of the translator entirely or provides a parameterised interface. Be careful of APIs, for example, put away methods, are parameterised.

If a parameterised API isn’t accessible, you should carefully escape unique characters utilising the appropriate escape grammar for that translator.

CONCLUSION:

HTML injection is similar to cross-site scripting vulnerability (XSS), which affects the client side. So, HTML injection can exploit in the same way as that of cross-site scripting which includes adding HTML data to the web application, temporary defacement of website etc… hence it is necessary to prevent web applications from HTML injection.

AUTHOR

Aravindan S

Security Engineer

BriskinfoSec Technology and Consulting  Pvt Ltd.,

https://www.linkedin.com/in/aravindhan-s-90b98787/

Cross Site Port Attack (XSPA)

 

CROSS SITE PORT ATTACK (XSPA)

INTRODUCTION:

A web application is helpless against Cross Site Port Attack if it forms client provided URLs and does not disinfect the backend reaction got from remote servers previously sending it back to the client. The responses, in specific cases, can be concentrated to distinguish benefit accessibility (port status, flags and so forth.) and even bring information from remote administrations in unique ways.

Detecting a potential XSPA vulnerability is very simple and if the web app takes URL as input and tries to make it connect to the port and analyse the output and I have been attempting this XSPA attack on a testing app http://testphp.vulnweb.com/

Once I visited the testing site, and here I have selected the image categories option on the site as follows

Later I have selected the required image file it takes me to the URL as follow

Once I Visited this site I have started to capture the backend response using Burp Suite tool

Burp Suite is a graphical tool for testing Web application security, and It was mainly developed to provide a comprehensive solution for web application security checks. and In addition to this basic functionality, it also has some extra features such as proxy server, scanner and intruder, the tool also contains more advanced options such as a spider, a repeater, a decoder, a comparer, an extender and a sequencer

I have cross checked this site using my localhost with some ports and captured the response in burp suite, and by this method, we can precisely analyse the response for each port

Here I have captured the response of the image URL and crossed check it with my localhost with port 80(HTTP), and I can see the response 200 OK (Normal response)

Once It fetches the average result, and you can also confirm this for other ports like 22(ssh), 21(ftp), 25(SMTP), 8080(https) etc. and you can check the result in browser as well.

During Port analysis, if any required port is closed, it fetches the result as

It also shows the response of 200, but it displays some warning like (failed to open) or connection refused etc. and if it shows this case of errors then you can confirm that the port is closed

In the above screenshot shows the different case of the port is opened but it shows the result without exposing the attacker IP on the server logs and it also reveals the backend service running on SSH

MITIGATION FOR XSPA ATTACK:

• Unauthorized URL’s access should be restricted
• Restrict Connectivity to the internal ports
• Whitelist IP address
• Disable Unwanted protocols and services.
• You can block your ports using firewall for better security please check the link below to block your inernal ports

Reference Link:

http://www.thewindowsclub.com/block-open-port-windows-8-firewall

CONCLUSION:

XSPA vulnerability attack mainly used to perform port scanning of a target using another vulnerable website and also an attacker can perform a DOS attack, Code Execution and other major attacks on other vulnerable  websites

Reference Link:

https://teamultimate.in/cross-site-port-attack-xspa-tutorial/

http://indiatriks.blogspot.in/2012/07/xspa-cross-site-port-attack.html

AUTHOR

RamKumar G

SecurityEngineer

BriskInfoSec Technology and Consulting PVT LTD

Find  me @ https://www.linkedin.com/in/ram-kumar-3439b511a/

How can Insecure CORS lead to a biggest security threat for your application?

HOW CAN INSECURE CORS LEAD TO A BIGGEST SECURITY THREAT FOR YOUR APPLICATION?

WHAT IS THE MEANING OF AN ORIGIN?

Two websites are said to have same origin if both have following in common:

• Scheme (http, https)
• Host name (google.com, facebook.com, briskinfosec.com)
• Port number (80, 4657, 7777)

So, sites http://example.com and http://example.com/settings have same origin. But https://example.com:4657 and http://example.com:8080/settings have different origins.

The ‘Same Origin Policy’ restricts how a script loaded from one origin can interact with a resource from another origin. It is an important built-in security mechanism for browsers for isolating potential malicious scripts.

WHAT IS CROSS ORIGIN RESOURCE SHARING?

It is the need of Web 2.0 to share resources across origins. Following are some examples:

• Cross Origin Writes: A website can POST data to an endpoint of another website.
• Cross Origin Embedding: A website can refer images from another website using <img src> tag. Also, an iframe using <iframe src> tag can be embedded if the source website allows it.

Apart from the above two scenarios, when one website reads data from another website, it is called as ‘Cross Origin Resource Sharing’ aka CORS.

CORS is a W3 specification that allows cross domain communications from the browser. It works by adding new HTTP Headers that describe the origins that are allowed cross domain information sharing.

In other words, CORS is used to relax the ‘Same Origin Policy’ for legitimate and trusted requests. It is an essential feature of Web 2.0 to support APIs that are exposed via web services to be accessible.

 Some noteworthy example of web applications supporting CORS: Google, YouTube, Flickr.

TWO MOST IMPORTANT CORS HEADERS:

• Origin: It is set by browser in every CORS request. Its value is the domain name from which the request originates.
• Access Control Allow Origin: It is set by server in every CORS response. Depending on its value, the browser decides if the response is allowed or not. It can be set to * (also called the wildcard character) to make resources public (However, this is not a good practise).

PRE-FLIGHT REQUEST

A pre-flight request is just a normal HTTP request that happens before the actual cross-domain communication. The logic behind this is to ensure the client and server are fully compatible (protocol, security, and so on) with each other before the data is actually exchanged. If they are not, then the relevant error is raised.

Please keep that in mind that a pre-flight request only triggers if:

• Custom HTTP headers are sent
• The body MIME-type is different than text/plain
• The HTTP method is different than GET or yuPOST

The following is a typical pre-flight request-response pair:

Request:

   OPTIONS / HTTP/1.1
   Origin: http://api.user.com
   Access-Control-Request-Method: PUT
   Host: api.example.com
   Accept-Language: en-US
   Connection: keep-alive
   User-Agent: Browser

Response:

   HTTP/1.1 204 No Content
   Access-Control-Allow-Origin: http://api.user.com
   Access-Control-Allow-Methods: GET, POST, PUT
   Content-Type: text/html; charset=utf-8

SIMPLE REQUEST

A simple CORS request is similar to a pre-flight request without the initial capability exchange sequence occurring. In a typical simple CORS request, the following sequence happens:

Request: http://example.com  – Origin A

Response: http://cdn.briskinfosec.com – Origin B

1. Origin A attempts to access the home page of a CDN running at origin B, http://cdn.briskinfosec.com , using CORS.
2. Origin A sends a GET request to the Origin B web server.

The Origin B server responds with Access-Control-Allow-Origin.

A SCENARIO TO EXPLOIT CORS VULNERABILITY:

In this demo we are going to use a vulnerable intranet application which has a secret located at ‘secret-cors-3.php’. It has an Admin who accesses it from his local environment. Its URL is: http://127.0.0.1:80/bwapp/.

As it is an intranet application, the attacker cannot interact with it remotely. Our goal as an attacker will be to capture the secret (from a remote internet location) by exploiting CORS vulnerability.

THE EXPLOITATION:

• The attacker hosts a website containing the malicious script for cross domain interaction.
• Victim i.e. the Admin of the intranet website visits the attacker’s website. Location http://127.0.0.1:4567

• Response is received from the attacker’s website containing the following malicious payload:

• As soon as the web page is loaded, ‘makeRequest’ method is called. The method initiates a cross domain request to capture the secret, to the vulnerable intranet application located at ‘http://127.0.0.1:80/bwapp/secret-cors-1.php’

• It fetches the response and stores it in the variable ‘secret’.

• The ‘Access-Control-Allow-Origin’ has value set to *. So, the malicious script now has the payload and it simply issues a GET request to the attacker’s web server. Attacker hosts another web server at location: http://127.0.0.1:7777

• Meanwhile, attacker monitors the logs of that web server. The payload gets executed and the logs receive the secret.

HOW TO MITIGATE IT?

• ‘Access-Control-Allow-Origin’ should be never set to * if the resource contains sensitive information.
• The mitigation is simple and just a proper configuration. Configure the Access-Control-Allow-Origin header to allow requests only from the domains that you trust. For e.g.: Access-Control-Allow-Origin: Saurabh.com. The below image illustrates that the CORS attack does NOT get executed when the server is configured with correct ‘Access-Control-Allow-Origin’ instead of a ‘Wildcard’ character.

• Make sure that in server side validation for checking the origin header value, you are comparing with absolute value and NOT with regular expression.
• For example: The following code does a comparison with regular expression:

RegEx(“^https://mail.example.com$”)

In the above validation, dots (.) mean any character. So, an attacker can bypass it by making the CORS request origin from following domain: https://mailxexample.com
The patched code will be:

            if($_SERVER[“HTTP_ORIGIN”] == “https://mail.example.com”)
                    {
                        header(“Access-Control-Allow-Origin: https://mail.example.com”);
                    } 

• Client should not trust the received content without sanitization because that will result in client side code execution. For example: If website abc.com trusts and fetches cross domain data from example.com. example.com has a malicious intent and starts sering malicious javascript to abc.com, then abc.com can protect its users from cross site scripting by sanitizing the received data and then presenting it to its users.

WHAT IF THE ORIGIN HEADER IS SPOOFED?

The point of origin header is not to protect the resources on the server, that task is up to server itself. Origin header is to protect the user. Following scenario demonstrates it:

• An attacker Charlie creates a malicious website M
• User Alice is tricked into visiting website M which tries to perform CORS action on server example.com that supports it.
• The domain example.com will be listed in website M’s list of allowed domains. So, the request will be rejected.
• The important point here is that M cannot spoof the origin header because the request is initiated from Alice’s browser.
• This can be done by Alice using a local proxy tool. But why would a victim hack himself, so this scenario is not real.

Another way, an attacker can do this, is by intercepting the request being a man in the middle. But if the attacker has access to the traffic, then capturing cookies and session ID are better options rather than changing the Origin header.

OWASP CATEGORY FOR CORS VULNERABILITY:

This vulnerability falls under to the category of ‘Security Misconfiguration’ of OWASP Top 10. The HTTP response header ‘Access-Control-Allow-Origin’ is not configured correctly and this creates the issue.

REFERENCES:

• In the demo, Bwapp was used as the target web application. It is a deliberately made insecure web application. More about it at –http://www.itsecgames.com/
• CORS Introduction –https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
• Same Origin and Cross Origin Policies:https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

We have discussed about what CORS is and how to exploit CORS vulnerability in the web application and API web services .It is important to   verify that the CORS are configured properly. As a p part of web application   we need to make sure the shared resource are secure and HTTP headers haven’t tampered. A CORS Exploitation can cause great consequences letting sensitive data to compromise.

BriskInfosec provides the best web application and API security test.  Discover the reason to conduct Application Security test with us.

Reach us – Contact@briskinfosec.com

Author

RadhaKrishnan

Security Engineer

BriskInfosec Technolagy and Consulting PVT LTD

https://www.linkedin.com/in/radhakrishnan-r-209607111/

How serious is Cross-site request forgery (XSRF or CSRF)?

 27 Dec 2017 Brisk Blogs BINT LAB

HOW SERIOUS IS CROSS-SITE REQUEST FORGERY (XSRF OR CSRF)?

Cross-site request forgery is attacking website as a legitimate and trusted user that tricks the victim submitting a malicious request. An attacker may forge a request to log the victim into a target website  CSRF, this could even lead to further damage.

The attacker often takes advantage of the fact that the user is already authenticated, but with some types of this attack. Impacts of successful CSRF exploits vary greatly based on the privileges of each victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. Utilizing social engineering, an attacker can embed malicious HTML or JavaScript code into an email or website to request a specific ‘task URL’. The task then executes with or without the user’s knowledge, either directly or by utilizing a Cross-Site Scripting flaw  It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can’t be circumvented

As a webmaster, however, you should not assume that you are protected from CSRF attacks when you see anti-CSRF tokens used in your web applications.

BURP SUITE:

Burp Suite is an integrated platform for performing security testing of web applications Burp to test the security of their applications. Some of Burp’s more advanced features will take further learning and experience to master It is not a point-and-click tool but is designed to be used by hands-on testers to support the testing process.

It was developed to provide a comprehensive solution for web application security checks. In addition to basic functionality, such as proxy server, scanner and intruder, the tool also contains more advanced options such as a spider, a repeater, a decoder, a comparer, an extender and a sequencer A penetration tester configures their Internet browser to route traffic through the proxy which then acts as a sort of Man In The Middle by capturing and analyzing each request and response to and from the target web application.

Step: 1 Here how to test CSRF test manually configure burp suite with your browser

Step: 2 Take authenticated web application Testing Site  You can log in using the credentials test:test.

Step 3: Then value in the field you can change the name email ID PH: NO Example Name Open Burp Proxy open the Tab Intercept On

Step: 4 Update the filed Submit the request so that it is captured  Burp Proxy  the Raw

Step: 5 Right Click Go to Engagement tools Generate CSRF PoC Option

Step : 6 PoC Generated Copy the HTML Open Note pad paste the HTML

Step:7 Modified the data As Test Username Email ID abc@gmail.com

Step: 8 Then Save It has test.html Open another browser login the Test site as test user click and Open the Test.html file submit the request

Step: 9 Attack has been successfully accounting information has been changed serves as an initial check to verify whether the attack is possible web application has been altered. A successful attack shows that the web application is vulnerable to CSRF

Cross-site request forgery is an understated attack technique that can be exceedingly deadly. In some cases it can lead to the complete compromise of a web-based system. We at BriskInfosec take care of the complete   web application security   testing helping the developers to develop their website and application in a secure manner.

For further information please feel free to get in touch with us @ Contact@briskinfosec.com

AUTHOR

Surya

Security Engineer

BriskInfosec Technology and consulting PVT LTD

Follow me @ https://www.linkedin.com/in/surya-shiva-43284b137/