For example, if those functions are used for generation of anti-CSRF tokens, tokens in file download links how easy will it be for attacker to guess those of other user? How he can do it?

Update: The paper I Forgot Your Password: Randomness Attacks Against PHP
Applications seems to be a canonical reading on the subject and contains detailed response to this question. However, it's quiet long and complicated so I'd want to see a more short excerpt that will point or show existence of exploit algorithm using which those functions can be broken.

@Polynomial Not a duplicate. D.W. specifically said in comments that that question is too broad and more specific questions should be asked about other functions. I ask about weaknesses in those exact functions.
–
Andrey BotalovAug 2 '12 at 10:11

If you want more details on the attacks, I updated my answer with additional links that explain some of these attacks. But do understand that some of the attacks do involve some mathematics. That's just how it goes, sometimes.
–
D.W.Aug 3 '12 at 18:04

"I want to see a more short excerpt that will point or show existence of exploit algorithm using which those functions can be broken" - The references already show a working attack algorithm, but it's not something you can fit in a fortune cookie. Sometimes attacks are complicated; that's just the way it is. (By the way, given the number of independent sources that state that these PRNGs are broken and insecure, and explain why, I think it would be wise to believe them.)
–
D.W.Aug 3 '12 at 18:44

Don't use either in any situation where you require cryptographic-strength randomness, including CSRF / password-equivilent tokens. A better alternative is the openssl_random_pseudo_bytes function, or reading from /dev/urandom. You could also look into implementing Blum Blum Shub, which is a strong (albeit slow) PRNG.

Bruteforce attack that you outlined in your answer to linked question will be impractical because of state of glibc is 31 word of 32 bits each. Again, see section 5.4 in this paper
–
Andrey BotalovAug 2 '12 at 12:27

@AndreyBotalov The bruteforce attack was only meant to be feasible for RNGs whose state is entirely determined from an initial seed. If an LFSR draws entropy from other sources, the bruteforce will be impossible.
–
PolynomialAug 2 '12 at 12:31

2

Don't use Blum-Blum-Shub. It is totally irrelevant here. Recommending Blum-Blum-Shub is like recommending that the person use Diffie-Hellman: it doesn't solve the problem, and is misleading.
–
D.W.Aug 3 '12 at 16:57

Those are all insecure. None of them are suitable for use in a CSRF token, or any other application requiring cryptographic strength. If you want more details why you should not use these methods, see the following resources:

As to your question regarding the paper, whatever algorithm you might come up with to generate a random string has probably been done before and the source code is likely available somewhere. If a PRNG is seeded with the current system clock in microsecond resolution, the search space is drastically reduced requiring only a few hundred thousand attempts. Combine that with maybe a few hundred common algorithms and you're looking at potentially mere seconds of CPU to reverse-engineer a token and synchronize with a remote system clock. After that, the application's security is hosed.

I guess the question is, will anyone care to hack your website at that level? Finding a SQL injection opportunity is generally a much easier route than trying to reverse-engineer a token scheme. Low-hanging fruit is more desirable to a hacker.