The attacker has to be able to issue requests on behalf of the user with injected "canary" strings. I fail to see a practical exploit where one can do this and wouldn't have access to the secret in the response anyway. What am I missing?
Does any GET or POST URI endpoint in your application accept parameters? Do none of those parameters impact the output of the application? That set of circumstances is extraordinarily common.
The request has to be issued by the attacker from the victim's browser. If the attacker can do that, why is he unable to read the response to that request?
Edit: I think I can see a scenario where a third-party website does these requests via an <iframe> or an <img>. I'm not sure there's a way to do POST quite as easily.
Do you understand how CSRF works? Just think of it in terms of CSRF. Since the attacker is trying to infer page content, they don't care that the server rejects all the probing requests, so CSRF protection doesn't help you as the attacker carries out the BREACH/CRIME stuff. If the result of the attack is an inferred CSRF token, they then cap the whole exploit off with a (now working) actual CSRF attack.
I understand how the attack works, the question was about how a practical exploit would actually be carried out. I've figured out how one would issue GET requests from the right environment, but I don't know if the same is possible for POST.
No, you're missing that the original GET requests can be performed in some cases over HTTP, either by forgery or by surreptitiously spoofing the user's own browser into doing it. No need to have compromised the SSL/TLS.
There are plenty of job opportunities and the coders are relatively even more overpaid than in the West, so that's not the reason.
The real reason I believe is that people mostly can do this with impunity. There's very little being done for prevent or prosecute credit card fraud. In Ukraine and Russia CCs are still used very little, so this fraud hurts "the West" which is mostly seen as a good thing by the general population. Rampant piracy is practically encouraged for the same reason.
Of course this creates a barrier for doing legitimate business online. For example PayPal simply does not allow merchant accounts from Ukraine and Russia to reduce fraud. These countries are the safe haven for hosting illegal content etc. It would benefit local programmers to clean up the reputation of the country and to my great annoyance people just do not realize this. Crooks are accepted as keynote speakers at business conferences etc (they do make money, so what's the problem?)
Things like regulatory capture make it hard for small players to get started in entrenched industries. Some examples: telecommunications (getting leases on existing pipes to sell your services), meat processing (look at the regs that small producers like Polyface Farms have to comply with), car manufacturing (look at the opposition Tesla is facing trying to sell direct to the consumer) -- and yes, banking.
I think there's an analogous problem with encryption and GPG: like with credit unions (USAA in particular) there's an easy solution out there, but relatively few people use it.
Just curious, what benefits do you get from simple.com that USAA does not provide? I looked at it in the beginning but it didn't seem to add anything, perhaps that's changed.
That's a great question. I like the experience of simple. I get push notifications when I swipe my card. I enjoy the "Safe to spend" amount that takes into account my goals. Photo check deposit is great too. It's early days for them, but I like backing that horse.
USAA is a great company. They give you ATM fee reimbursements which is a huge benefit over simple. I feel guilty getting them since they have to eat that cost. In dealing with them, they're always pleasant and friendly, but they have policies like photo check deposit is only available if you're ex-military.
Would you trust your savings to a startup? Maybe if there was FDIC insurance. Would you expect the federal government to trust everyone's money to startups?
No way.
While banks may be horrible to their retail customers, the regulations that protect them exist for a reason. The current state of affairs is far, far better than having hundreds of thousands of banks which could fail and drop off the map with all of their customers' assets at any time.
FDIC insurance has changed that, but a prudent insurance company would not insure a startup bank, or if it did, it would need to collect so much for that risk that the startup bank couldn't offer anything competitive. The FDIC is almost certainly not going to do this.
The code generator we use (at my job; not crypto) was written in Coq and formally verified to generate code with certain properties, given properties of the input.
I assume that the crypto group I know, who developed most of the code generator I use, takes similar measures to make sure that their verified "theorems" translate correctly to code.
The unverified stage is actually the hardware, which is an open problem.
Pressure equipment, specifically sort of mid-scale items for laboratory and small-batch use.
Our low level code (ie, directly controlling machines) is written in the SPARK environment. This code tends not to get updated often, and has a high level of verification to it. It's what actually handles the pressure cut-offs (ie, hard limits on the machine), turning vales, etc.
Our middleware code is based on a specially developed VM that gets code generated for it in Coq, to ensure that it doesn't choke or become unresponsive. However, it's not directly responsible for safety control and has somewhat laxer restrictions.
Coq is useful for demonstrating that the middleware analytics will complete in a given time profile and not crash out the server on erroneous input.
Right, but it's much less of a leap of faith, IMHO. Besides, if you turn off optimisations you can be reasonably sure the compiler didn't do something unintended.
Wikimedia employs a lot of people, I personally do not donate because I believe they employ way too many. Also pretty much all costs are already covered by corporate sponsors like Google.
I remember reading though a page where they listed their employees and I remember it was 100+, I wanted to include the link in my comment, buy couldn't find it this time.
So they're getting paid less than the going rate, at least the software engineers are. Interesting.
Have you considered many of them that are on the payroll might have other jobs and so the volume is to make up for the fact that they're not all 40+ hours full time? I think this is much more complicated than we could first expect
Without a breakdown of where the employees are located and their positions, you can't possibly say anyone at Wikimedia is getting paid more or less than the going rate.
'Sponsor' implies some sort of continuing relationship or cross-promotion or consideration received, so it's not very accurate to say Wikipedia has 'corporate sponsors'. The Wikimedia Foundation has received some corporate donations (including from Google), but those are a relatively small portion of their budget compared to tiny individual donations.
