92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
# File 'components/checks/active/csrf.rb', line 92
def self.info
{
name: 'CSRF',
description: %q{
It uses differential analysis to determine which forms affect business logic and
checks them for lack of anti-CSRF tokens.
(Works best with a valid session.)
},
elements: [ Element::Form ],
author: 'Tasos "Zapotek" Laskos <[email protected]> ',
version: '0.4.1',
issue: {
name: %q{Cross-Site Request Forgery},
description: %q{
In the majority of today's web applications, clients are required to submit forms
which can perform sensitive operations.
An example of such a form being used would be when an administrator wishes to
create a new user for the application.
In the simplest version of the form, the administrator would fill-in:
* Name
* Password
* Role (level of access)
Continuing with this example, Cross Site Request Forgery (CSRF) would occur when
the administrator is tricked into clicking on a link, which if logged into the
application, would automatically submit the form without any further interaction.
Cyber-criminals will look for sites where sensitive functions are performed in
this manner and then craft malicious requests that will be used against clients
via a social engineering attack.
There are 3 things that are required for a CSRF attack to occur:
1. The form must perform some sort of sensitive action.
2. The victim (the administrator the example above) must have an active session.
3. Most importantly, all parameter values must be **known** or **guessable**.
Arachni discovered that all parameters within the form were known or predictable
and therefore the form could be vulnerable to CSRF.
_Manual verification may be required to check whether the submission will then
perform a sensitive action, such as reset a password, modify user profiles, post
content on a forum, etc._
},
references: {
'Wikipedia' => 'http://en.wikipedia.org/wiki/Cross-site_request_forgery',
'OWASP' => 'https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)',
'CGI Security' => 'http://www.cgisecurity.com/csrf-faq.html'
},
tags: %w(csrf rdiff form token),
cwe: 352,
severity: Severity::HIGH,
remedy_guidance: %q{
Based on the risk (determined by manual verification) of whether the form submission
performs a sensitive action, the addition of anti-CSRF tokens may be required.
These tokens can be configured in such a way that each session generates a new
anti-CSRF token or such that each individual request requires a new token.
It is important that the server track and maintain the status of each token (in
order to reject requests accompanied by invalid ones) and therefore prevent
cyber-criminals from knowing, guessing or reusing them.
_For examples of framework specific remediation options, please refer to the references._
}
}
}
end
|