SQL Clone Request failed anti-forgery validation

• 
  SQL Clone Server uses double-submit cookie verification as a mitigation against cross-site request forgery. Although CSRF is a browser concern, our PowerShell cmdlets and therefore Azure DevOps extension also need to send requests that comply with that contract.
  
  This means that requests should have a header and a cookie set to matching values. The cmdlets and therefore extension that uses them sets these to constants. Is there any possibility that the headers or cookies are being transformed/stripped between the Azure DevOps agent and SQL Clone Server, perhaps by a proxy?

  ChrisHurley September 12, 2019 10:09

  - 0 +
• 
  There could be a proxy do to the connections between Azure and our servers. Is there a way to disable the check? I don't have control over the network.
  

  Cat_Bill September 12, 2019 12:59

  - 0 +
• 
  I was able to confirm there is no proxy!
  

  Cat_Bill September 12, 2019 14:30

  - 0 +
• 
  Hm, interesting. This is a problem that we've heard of before with Azure DevOps, but haven't been able to explore properly.
  
  We could potentially explore this further with network tracing and/or a private build with some additional logging to see what headers/cookies we're receiving. Could you open a ticket with support@red-gate.com and mention this conversation?

  ChrisHurley September 12, 2019 17:17

  - 0 +
• 
  After doing a lot of testing it appears the error is caused by not using the root web address for the SQL Clone interface on the local server as the Server URL.
  
  When launching the SQL Clone interface (Web browser page) it does a redirect to http://<servername>:14145/dashboard. If you have the /dashboard in the Server URL box in Azure DevOps it causes the above CSRF error.
  
  Once I removed the /dashboard it worked correctly. This must have been altering the cookie. Wanted to post an update, so this is documented and others don't have this issue.

  CAT_Keith September 19, 2019 21:53

  - 0 +
• 
  Thanks for the update! That's really useful to hear about, and I'm glad it's now working.
  
  I'll have a look what options we have to prevent others getting into this situation in the future.

  ChrisHurley September 20, 2019 13:09

  - 0 +

Add comment

Please sign in to leave a comment.