A csrf attack is where the attacker can submit a request to the page without user knowing. It can be as easy as tricking a user to simply visit a page. If the user is still logged in to the website, the action in the request will be successful without adequate protection. The followings are examples of csrf attacks for GET and POST methods.
The typical prevention measure cited is to include a random,long token along with every request. As the token is needed to successfully validate the request, the attacker cannot construct a valid html page with correct token. Some applications will instead use a session wide csrf token instead of a per-request token. This has some usability improvements as per-request csrf token will limit the user from opening multiple pages as any new page opening will invalidate the previous request. However, it has slightly diminished security as if the attacker can monitor the traffic, he can generate correct html page within the time window the session token is valid.
Ideally, good csrf targets should be state changing instead of pure viewing states. However, it is not trivial to detect if a request is state changing. Therefore in our scanning, we limit ourselves to simply detecting requests that are not protected by per-request csrf tokens. Our exploit script is an html page with a tag for get request and form for POST requests instead of auto executing the request as the example above.
To reduce the number of false positives, we also filter out urls that can be accessed without loggin in. Algorithm steps:
crawl once without logging in
results1 <- crawl second time with login
results2 <- crawl third time with login
ignore all urls which can be accessed without logging in
flag the results in results2 which has the exact same parameter name and value as potentially vulnerable. Note that weak csrf protection mechanism where session token is used as csrf token, can also be detected because our crawler code can handle login with session headers(so that session token does not change and incorrectly flagged as secure)
A csrf attack is where the attacker can submit a request to the page without user knowing. It can be as easy as tricking a user to simply visit a page. If the user is still logged in to the website, the action in the request will be successful without adequate protection. The followings are examples of csrf attacks for GET and POST methods.
GET:
POST:
The typical prevention measure cited is to include a random,long token along with every request. As the token is needed to successfully validate the request, the attacker cannot construct a valid html page with correct token. Some applications will instead use a session wide csrf token instead of a per-request token. This has some usability improvements as per-request csrf token will limit the user from opening multiple pages as any new page opening will invalidate the previous request. However, it has slightly diminished security as if the attacker can monitor the traffic, he can generate correct html page within the time window the session token is valid.
Ideally, good csrf targets should be state changing instead of pure viewing states. However, it is not trivial to detect if a request is state changing. Therefore in our scanning, we limit ourselves to simply detecting requests that are not protected by per-request csrf tokens. Our exploit script is an html page with
atag for get request andformfor POST requests instead of auto executing the request as the example above.To reduce the number of false positives, we also filter out urls that can be accessed without loggin in. Algorithm steps: