Nilesh Kumar

Is it a problem? I think no, as long as the token is Per Page, One-time use token. Actually in one of the application, we had recommended to implement anti-CSRF tokens. When the application came back to us for verification process, we found that the application was implementing some sort of CSRF tokens, which were: 1) Going in GET request ie. were being added to URL. 2) Were being generated per page. 3) Were one-time tokens. The only concern was the token in GET request. I mean it can be said that it is certainly not a best practice but the potential risk is very minimal. In a scenario where it can be exploited depends on following constraints: 1. The victim should be logged into the application (obvious). 2. The CSRF token must be transmitted in a GET request. 3. The attacker must be able to capture the token or from a repository (log files, browser cache etc). 4. The attacker needs to trick the victim to click on the crafted link. 5. The victim's session that holds the exposed to...

We had a discussion with our colleagues over XSS issue found in one application. Initially there was not input validation at all-you can insert simple script tag and execute XSS. Following our recommendations they filtered out certain special characters like (>,<," etc) also they encoded them at time of output. Fair enough? No. Actually they implemented half of the recommendations- ie. they worked on blacklisting and left out whitelisting. There are a number of models to think about when designing a data validation strategy, which are listed from the strongest to the weakest as follows. 1.Exact Match (Constrain) 2.Known Good (Accept) 3.Reject Known bad (Reject) 4.Encode Known bad (Sanitize) They were implementing last two of strategies only. So the application was now filtering out normal XSS vectors like "><script>alert(...);</script> based attacks. But what happens when we provide eventhalders like onmouseover,onload etc-XSS executed. When we brought...