QC does this logon call to http://qc.embarcadero.com/coBugCGI.exe/soap/ICDSReportPublicInterface
Posted by jpluimers on 2017/06/09
I drafted this in 2014 and given the recent QC news:
I was quite shocked to see that the Embarcadero QC client logs in over HTTP, not over HTTPS, especially since it passes the password in plain text.
QC does this logon call to http://qc.embarcadero.com/coBugCGI.exe/soap/ICDSReportPublicInterface:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| POST http://qc.embarcadero.com/coBugCGI.exe/soap/ICDSReportPublicInterface HTTP/1.1 | |
| SOAPAction: "urn:CDSReportPublicInterfaceIntf-ICDSReportPublicInterface#Login" | |
| Content-Type: text/xml; charset="utf-8" | |
| User-Agent: Borland SOAP 1.1 | |
| Host: qc.embarcadero.com | |
| Content-Length: 665 | |
| Proxy-Connection: Keep-Alive | |
| Pragma: no-cache | |
| <?xml version="1.0"?> | |
| <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><NS1:Login xmlns:NS1="urn:CDSReportPublicInterfaceIntf-ICDSReportPublicInterface"><EMail xsi:type="xsd:string">nobody@example.org</EMail><Passcode xsi:type="xsd:string">password</Passcode><ClientID xsi:type="xsd:string">QCWINCLNT</ClientID><BDN xsi:type="xsd:string">1</BDN></NS1:Login></SOAP-ENV:Body></SOAP-ENV:Envelope> |
Time to cut down on my usage of QC.
–jeroen
via: QC does this logon call to http://qc.embarcadero.com/coBugCGI.exe/soap/ICDSReportPublicInterface.
The Wiert Corner - irregular stream of stuff 
Jeffrey Dyer said
Do you really use the same login details for your online banking and Embarcadero account?
jpluimers said
I don’t. But the EDN account has all your product license information attached to it.
It isn’t rocked science to put an internal site behind TLS either: https://continuaci.pluimers.com encapsulates my (non TLS) ContinuaCI site.
Such a solution is common practice in IT infrastructure called TLS/SSL offloading/acceleration/termination.
If a company cannot or does not want to provide TLS/SSL for credentials, it is a clear admission of their IT incompetence.
In their current state, it’s just a matter of time until they get a GPDR fine (see the comment by KMorwath in this thread and https://en.wikipedia.org/wiki/General_Data_Protection_Regulation).
Jeffrey Dyer said
“I don’t. But the EDN account has all your product license information attached to it.”
Good point.