[x] 1.1 SKF checklist requirement
More information
Filename injection Path traversal
Description:
A Path Traversal attack aims to access files and directories that are stored outside the web root folder. By browsing the application, the attacker looks for absolute links to files stored on the web server. By manipulating variables that reference files with dotdotslash (../); sequences and its variations, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and critical system files, limited by system operational access control. The attacker uses ../../ sequences to move up to root directory, thus permitting navigation through the file system. This attack can be executed with an external malicious code injected on the path, like the Resource Injection attack.
Solution:
The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing
usersubmitted input to any filesystem/framework API. If this is not possible the application
can maintain a white list of files, that may be included on the page, and then use an identifier
(for example the index number) to access the selected file. Any request containing an invalid
identifier has to be rejected, in this way there is no attack surface for malicious users to
manipulate the path.
[ ] 1.2 Another SKF requirement
More information
Cross site request forgery
Description:
CrossSite Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site,
email, blog, instant message, or program causes a users Web browser to perform an unwanted
action on a trusted site for which the user is currently authenticated.
The impact of a successful crosssite request forgery attack is limited to the
capabilities exposed by the vulnerable application. For example, this attack could result
in a transfer of funds, changing a password, or purchasing an item in the users context.
In effect, CSRF attacks are used by an attacker to make a target system perform a
function (funds Transfer, form submission etc.) via the targets browser without
knowledge of the target user at least until the unauthorised function has been committed.
Solution:
To arm an application against automated attacks and tooling you need to use unique tokens
which are included into the forms of an application, API calls or AJAX requests.
Any state changing operation requires a secure random token (e.g CSRF token) to prevent
against CSRF attacks. Characteristics of a CSRF Token are a unique, large random
value generated by a cryptographically secure random number generator.
The CSRF token is then added as a hidden field for forms and validated on the sever side whenever
a user is sending a request to the server.
Note :
Whenever the application is an REST service and is using tokens such as JWT tokens, whenever these tokens are being sent
in the application headers rather than stored in cookies the application should not be suspectible to CSRF attacks for a succesfull CSRF attacke depends on the browsers cookie jar.
[ ] 1.3 The final requirement for this topic
More information
Session IDs do not timeout (idl)
Description:
All sessions should implement an idle or inactivity timeout.
This timeout defines the amount of time a session will remain active in case there is no
activity in the session, closing and invalidating the session upon the defined idle period
since the last HTTP request received by the web application for a given session ID.
The idle timeout limits the chances an attacker has to guess and use a valid session ID
from another user. However, if the attacker is able to hijack a given session,
the idle timeout does not limit the attacker's actions, as he can generate activity on
the session periodically to keep the session active for longer periods of time.
Session timeout management and expiration must be enforced on the serverside. If the client is
used to enforce the session timeout, for example using the session token or other client
parameters to track time references (e.g. number of minutes since login time), an attacker
could manipulate these to extend the session duration.
Solution:
All user sessions should timeout based on logic serverside in order to decrease an
attackers attack vector on the user session.
[ ] 1.4 SKF GitHub integration
More information
Session IDs do not timeout (idl)
Description:
All sessions should implement an idle or inactivity timeout.
This timeout defines the amount of time a session will remain active in case there is no
activity in the session, closing and invalidating the session upon the defined idle period
since the last HTTP request received by the web application for a given session ID.
The idle timeout limits the chances an attacker has to guess and use a valid session ID
from another user. However, if the attacker is able to hijack a given session,
the idle timeout does not limit the attacker's actions, as he can generate activity on
the session periodically to keep the session active for longer periods of time.
Session timeout management and expiration must be enforced on the serverside. If the client is
used to enforce the session timeout, for example using the session token or other client
parameters to track time references (e.g. number of minutes since login time), an attacker
could manipulate these to extend the session duration.
Solution:
All user sessions should timeout based on logic serverside in order to decrease an
attackers attack vector on the user session.
Security knowledge framework!
More information
More information
More information
More information