O que eu mais gostei de ver no guide foram algum pontos que sempre mencionamos em análises e que geralmente não são tratados por desenvolvedores:
Página 23 - Strong log-out and session management
Proper session handling is one of the most important parts of Web application security. At the most fundamental level, sessions must be initiated, managed, and terminated in a secure manner. If a product employs an authenticated session, it must begin as an encrypted authentication event to avoid session fixation.
• A session identifier/token must never be transmitted via the URL to avoid side-jacking via the referrer header or browser history.
• All session data must be maintained on the server, not the client, to avoid tampering.
• Sessions must be completely terminated on the server side via logout and timeout mechanisms. When multiple sessions are tied to a single authentication event, all of the sessions tied to that event must be terminated by logout/time-out.
The following items must be met as part of the exit criteria for this recommendation:
• When multiple sessions are tied to a single user identity, they must be collectively terminated on the server side at timeout or logout.
• Authentication events must invalidate unauthenticated sessions and create a new session identifier.
• Logout functionality is available on every page.
• Session state, outside of a single identifier, is maintained on the server and not accepted from the user (including via cookie or header).
• Session tokens are not present in the URI.
• Timeout functionality is present and timeout thresholds are documented along with the rationale.
Página 28 - Avoid EXEC in stored procedures
Using stored procedures helps to mitigate the SQL injection threat to a great extent since type checking is available for parameters. If the attacker supplies input that does not match the type constraints, the stored procedure will throw an exception. In the vast majority of the cases, this exception should be properly handled within the application.
However, if the stored procedures perform string manipulation in their code and then execute that query using the "exec @sql" construct, incorrect handling of user input can produce the same SQL injection vulnerability as would be seen at the application layer.
EXEC and EXECUTE are prohibited in T-SQL stored procedures except in the case where they are used to call other stored procedures. Using EXEC to call ad-hoc SQL is not allowed. For example, the following is allowed:
EXEC('MyStoredProc')
But the following is prohibited:
EXEC('SELECT * FROM Foo')
Note that there are some situations in which it is impossible to write a parameterized T-SQL query. For instance, you cannot specify table names or column names as parameters. Similarly you cannot parameterize the operands of some operators, such as the IN operator.
If your product falls into one of these situations or any other case in which you believe the only reasonable option is to use EXEC with ad-hoc SQL, investigate an alternative design or implement appropriate escaping logic to mitigate SQL injection attacks.
Exit criteria for this requirement is that stored procedures contain no calls to EXEC or EXECUTE (except for calls to EXEC other stored procedures).
Página 32 - HTTPOnly Cookies
To mitigate the risk of information disclosure with a cross-site scripting attack, a new attribute was introduced to cookies for Internet Explorer 6 SP1 and is now in use in all current browsers. This attribute specifies that a cookie is not accessible through script. By using HTTP-only cookies, a Web application reduces the possibility that sensitive information contained in the cookie can be stolen via script. Watcher, a Web security testing tool, can help you meet this recommendation.
All HTTP-based applications that use cookies must specify HttpOnly in the cookie definition for all cookies not explicitly required by legitimate scripts in the Web page. For example:
Set-Cookie: USER=123; expires=Wednesday, 10-Feb-2010 23:12:40 GMT; HttpOnly"
Página 33 - ClickJacking defense
For each page that could contain user controllable content, you should use a "frame-breaker" script and include the HTTP response header named X-FRAME-OPTIONS in each authenticated page. The Watcher tool may be of use in meeting this recommendation. The exit criteria for this recommendation is as follows:
1. A "frame-breaker" script is included in each authenticated page to prevent unintentionally framing.
2. The X-FRAME-OPTIONS header has been added to all authenticated page HTTP responses that should not be framed (for example, DENY) or is utilized to only allow trusted sites to frame site content (for example, the current site with the use of SAMEORIGIN).
Se em versões anteriores algumas pessoas criticavam por não atender claramente as características de aplicação web, a cada nova versão este cenário vem sendo melhorado.
Nenhum comentário:
Postar um comentário