CSRF vulnerability allows disabling Gmail contacts link for user referrals

How it was found

Summary:

#Hi team

when user add ==Referrals== to his account use https://crm.na1.insightly.com/users/referrals he will get id to his linked account so when he try to disable the linked account in ==CONNECTED APPLICATION SETTINGS== in the end point https://crm.na1.insightly.com/users/usersettings ==request== contain the id will be send https://crm.na1.insightly.com/Users/GoogleDisable/2023554 The vulnerable endpoint allows an authenticated user to change the email address associated with their account and ==Remove it==(disableit) However, it does not sufficiently verify that requests were intentionally performed by the user (e.g. by checking the values of HTTP headers a).

#Step's 1-First we need to account to confirm the issue account ==A== and ==B== 2-Go to https://crm.na1.insightly.com/users/referrals and add Google Referrals to both account's use two account's 3-Now the linked account will have two id not the same 4-From account ==A== Go to https://crm.na1.insightly.com/users/usersettingstry to disable the linked account and capitsher the request use ==Burp proxy== 5- Generate the POC use the Disable Request 6-when open the link from account ==B== the bug will be exploite

#Proof-of-Concept (PoC) This is the code used for the demonstration video attached to this report

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://crm.na1.insightly.com/Users/GoogleDisable/2026462">
      <input type="hidden" name="&#95;pjax" value="&#35;main" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

when send the request the id will auto been change so victim linked account will be disabled

Impact

An attacker can exploit this vulnerability in order to disable account linked or take over accounts by associating them with an address controlled by the attacker, then performing a password reset. In order for the attack to be successful, the target user account must be associated with an unconfirmed email address, and the target user must visit an attacker-controlled website while logged in.