Web Dev

Snipplely–Guarde o seu precioso código

Publicado em 27/10/201014/09/2015 por homdigitalis

Snipplely – Guarde o seu precioso código

Criado por Pedro Simões em 26 de Outubro de 2010 | 15 comentários

Todos aqueles que programam, seja em que linguagem for, sabem o bem que certos pedaços de código que executamos com frequência ou que nos deram muito trabalho a conseguir valem mais do que certas pedras preciosas.

Por norma tendemos a guardar esse código para o reaproveitarmos noutras ocasiões. Colocamo-lo em ficheiros de texto sem qualquer ordenação e tipicamente “ao molho”, misturado com o resto de código e funções que vamos recolhendo e inventando. Mas e se usássemos um software que nos permitisse ter esse código organizado por funções e por linguagens de programação? O Snipplely permite-vos fazer isso de forma bem simples.

Esta aplicação, desenvolvida para Air da Adobe, permite que organizem o vosso código de forma simples, e com a possibilidade de adicionarem notas a esse código. São snippets que são arrumados e agrupados da forma que melhor vos convier.

O Snipplely tem ainda a grande vantagem de conseguir mostrar o código com a sintaxe em destaque, sendo esta marcada por cores. As linguagens que podem ser destacadas são as seguintes:

Javascript
Ruby
CSS
PHP

A interface está agrupada em duas zonas, uma onde estão os vossos grupos e outra onde podem ter os vossos snippets. Na primeira podem criar entradas por função ou por linguagem de programação.

Toda a criação e remoção de grupos ou de está snippets concentrada na zona inferior do final Snipplely. Ai encontram um botão + e um –, que serve respectivamente para criar ou remover/renomear grupos ou snippets.

Depois de criados os vossos Grupos é hora de começarem a colocar os vossos snippets. Para cada um deles é possível colocarem texto ou código. Tanto quanto queiram, podendo inclusive adicionar alternadamente cada um deles.

Definam então o título, uma descrição e depois disso o código e o texto pretendido. Se pretenderem podem arrastar snippets entre grupos.

O único requisito (óbvio) que esta ferramenta necessita é que tenham instalado o Air. E por ser desenvolvido para esta plataforma é utilizável em qualquer um dos sistemas operativos mais comuns (Windows, Linux ou Mac).

Esta ferramenta é uma grande ajuda para todos aqueles que programam de forma mais intensiva e que têm algumas funções muito pessoais ou para guardar código que utilizam de forma recorrente e que pretendem guardar religiosamente.

Usem-no para se organizarem um pouco mais e assim serem mais produtivos. Tentem e vão ver que não querem outra coisa!

Licença: Freeware
Sistemas Operativos: Windows/ Mac/ Linux
Download: Snippely 1.1 [238.42KB]
Download: Adobe AIR
Homepage: Snippely

Asterisk – transforme o seu PC numa central telefónica

Publicado em 26/10/201016/09/2015 por homdigitalis

Asterisk – Transforme um PC numa Central Telefónica

Criado por Pedro Pinto em 24 de Outubro de 2010 | 1 comentário

Asterisk 1.8.0 com Google Voice e suporte para IPv6

Quando se fala em VoIP (Voz sobre IP) e soluções gratuitas, é quase inevitável não falar do popular Asterisk. Para quem não conhece, o Asterisk é um software de código aberto que permite “transformar” um simples computador num servidor de comunicações como se de uma central telefónica multi-protocolo se tratasse.

A Digium, é a empresa que promove o Asterisk, mas actualmente é a comunidade de programadores que contribui fortemente para os avanços da aplicação. Recentemente foi lançada a versão 1.8.0 com algumas novidades interessantes.

O Asterisk tem suporte para os principais protocolos de abertos, dos quais se destacamos o SIP, MGCP e IAX.

Principais características do Asterisk

Sistema de telefonia IP-PBX;
Distribuidor Automático de Chamadas (DAC);
Unidade de Resposta Audível (URA);
Correio de Voz com integração com o correio electrónico;
Relatório e estatísticas das chamadas;
Facilidade de administração e gestão através da Web;
Compatível com os PBX’s analógicos;
Compatível com os telefones digitais IP;
Conectividade com troncos analógicos e digitais;
Sistema voltado para pequenas e médias empresas

Relativamente à versão 1.8, existem algumas novidades das quais destacamos:

Suporte para o protocolo IPv6 no driver SIP Channel
Suporte a CPI (Connected Party Identification)
Suporte para o Google Talk e Google Voice
Integração com o calendário do Microsoft Exchange, CalDav iCalendar
Segurança no protocolo RTP

Confira todas as novidades aqui

Deixamos aqui um vídeo de 47 min, de introdução ao Asterisk.

<7p>
Segundo informações no site do projecto, instalar o Asterisk demora menos de 30 minutos, tendo o utilizador ao seu dispor um interface simples, web-based, para proceder a todas as configurações. Está interessado? Então comece por aqui
Licença: GPL
Download: Asterisk 1.8 64 bits (587 MB) | Asterisk 1.8 32 bits (605 MB)
Homepage: Asterisk

Common Security Mistakes

Publicado em 24/10/201016/09/2015 por homdigitalis

Web application developers today need to be skilled in a multitude of disciplines. It’s necessary to build an application that is user friendly, highly performant, accessible and secure, all while executing partially in an untrusted environment that you, the developer, have no control over. I speak, of course, about the User Agent. Most commonly seen in the form of a web browser, but in reality, one never really knows what’s on the other end of the HTTP connection.

There are many things to worry about when it comes to security on the Web. Is your site protected against denial of service attacks? Is your user data safe? Can your users be tricked into doing things they would not normally do? Is it possible for an attacker to pollute your database with fake data? Is it possible for an attacker to gain unauthorized access to restricted parts of your site? Unfortunately, unless we’re careful with the code we write, the answer to these questions can often be one we’d rather not hear.

We’ll skip over denial of service attacks in this article, but take a close look at the other issues. To be more conformant with standard terminology, we’ll talk about Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Phishing, Shell injection and SQL injection. We’ll also assume PHP as the language of development, but the problems apply regardless of language, and solutions will be similar in other languages.

[Offtopic: by the way, did you already get your copy of the Smashing Book?]

1. Cross-site scripting (XSS)

Cross-site scripting is an attack in which a user is tricked into executing code from an attacker’s site (say evil.com) in the context of our website (let’s call it http://www.mybiz.com). This is a problem regardless of what our website does, but the severity of the problem changes depending on what our users can do on the site. Let’s look at an example.

Let’s say that our site allows the user to post cute little messages for the world (or maybe only their friends) to see. We’d have code that looks something like this:

1
<?php

2
echo "$user said $message";

3
?>

To read the message in from the user, we’d have code like this:

1
<?php

2
$user = $_COOKIE['user'];

3
$message = $_REQUEST['message'];

4
if($message) {

5
save_message($user, $message);

6
}

7
?>

8
<input type="text" name="message" value="<?php echo $message ?>">

This works only as long as the user sticks to messages in plain text, or perhaps a few safe HTML tags like <strong> or <em>. We’re essentially trusting the user to only enter safe text. An attacker, though, may enter something like this:

1
Hi there.../code

(Note that I’ve changed http to h++p to prevent auto-linking of the URL).

When a user views this message on their own page, they load bad-script.js into their page, and that script could do anything it wanted, for example, it could steal the contents of document.cookie, and then use that to impersonate the user and possibly send spam from their account, or more subtly, change the contents of the HTML page to do nasty things, possibly installing malware onto the reader’s computer. Remember that bad-script.js now executes in the context of http://www.mybiz.com.

This happens because we’ve trusted the user more than we should. If, instead, we only allow the user to enter contents that are safe to display on the page, we prevent this form of attack. We accomplish this using PHP’s input_filter extension.

We can change our PHP code to the following:

01
<?php

02
$user = filter_input(INPUT_COOKIE, 'user',

03
FILTER_SANITIZE_SPECIAL_CHARS);

04
$message = filter_input(INPUT_POST | INPUT_GET, 'message',

05
FILTER_SANITIZE_SPECIAL_CHARS);

06
if($message) {

07
save_message($user, $message);

08
}

09
?>

10
<input type="text" name="message" value="<?php echo $message ?>">

Notice that we run the filter on the input and not just before output. We do this to protect against the situation where a new use case may arise in the future, or a new programmer comes in to the project, and forgets to sanitize data before printing it out. By filtering at the input layer, we ensure that we never store unsafe data. The side-effect of this is that if you have data that needs to be displayed in a non-web context (e.g. a mobile text message/pager message), then it may be unsuitably encoded. You may need further processing of the data before sending it to that context.

Now chances are that almost everything you get from the user is going to be written back to the browser at some point, so it may be best to just set the default filter to FILTER_SANITIZE_SPECIAL_CHARS by changing filter.default in your php.ini file.

PHP has many different input filters, and it’s important to use the one most relevant to your data. Very often an XSS creeps in because we use FILTER_SANITIZE_SPECIAL_CHARS when we should have usedFILTER_SANITIZE_ENCODED or FILTER_SANITIZE_URL or vice-versa. You should also carefully review any code that uses something like html_entity_decode, because this could potentially open your code up for attack by undoing the encoding added by the input filter.

If a site is open to XSS attacks, then its users’ data is not safe.

2. Cross-site request forgery (CSRF)

A CSRF (sometimes abbreviated as XSRF) is an attack where a malicious site tricks our visitors into carrying out an action on our site. This can happen if a user logs in to a site that they use a lot (e.g. e-mail, Facebook, etc.), and then visits a malicious site without first logging out. If the original site is susceptible to a CSRF attack, then the malicious site can do evil things on the user’s behalf. Let’s take the same example as above.

Since our application reads in input either from POST data or from the query string, an attacker could trick our user into posting a message by including code like this on their website:

1
<img src="h++p://www.mybiz.com/post_message?message=Cheap+medicine+at+h++p://evil.com/"

2
style="position:absolute;left:-999em;">

Now all the attacker needs to do, is get users of mybiz.com to visit their site. This is fairly easily accomplished by, for example, hosting a game, or pictures of cute baby animals. When the user visits the attacker’s site, their browser sends a GET request to http://www.mybiz.com/post_message. Since the user is still logged in to http://www.mybiz.com, the browser sends along the user’s cookies, thereby posting an advertisement for cheap medicine to all the user’s friends.

Simply changing our code to only accept submissions via POST doesn’t fix the problem. The attacker can change the code to something like this:

1
<iframe name="pharma" style="display:none;"></iframe>

2
<form id="pform"

3
action="h++p://www.mybiz.com/post_message"

4
method="POST"

5
target="pharma">

6
<input type="hidden" name="message" value="Cheap medicine at ...">

7
</form>

8
<script>document.getElementById('pform').submit();</script>

Which will POST the form back to http://www.mybiz.com.

The correct way to to protect against a CSRF is to use a single use token tied to the user. This token can only be issued to a signed in user, and is based on the user’s account, a secret salt and possibly a timestamp. When the user submits the form, this token needs to be validated. This ensures that the request originated from a page that we control. This token only needs to be issued when a form submission can do something on behalf of the user, so there’s no need to use it for publicly accessible read-only data. The token is sometimes referred to as a nonce.

There are several different ways to generate a nonce. For example, have a look at the wp_create_nonce,wp_verify_nonce and wp_salt functions in the WordPress source code. A simple nonce may be generated like this:

1
<?php

2
function get_nonce() {

3
return md5($salt . ":" . $user . ":" . ceil(time()/86400));

4
}

5
?>

The timestamp we use is the current time to an accuracy of 1 day (86400 seconds), so it’s valid as long as the action is executed within a day of requesting the page. We could reduce that value for more sensitive actions (like password changes or account deletion). It doesn’t make sense to have this value larger than the session timeout time.

An alternate method might be to generate the nonce without the timestamp, but store it as a session variable or in a server side database along with the time when the nonce was generated. That makes it harder for an attacker to generate the nonce by guessing the time when it was generated.

1
<?php

2
function get_nonce() {

3
$nonce = md5($salt . ":" . $user);

4
$_SESSION['nonce'] = $nonce;

5
$_SESSION['nonce_time'] = time();

6
return $nonce;

7
}

8
?>

We use this nonce in the input form, and when the form is submitted, we regenerate the nonce or read it out of the session variable and compare it with the submitted value. If the two match, then we allow the action to go through. If the nonce has timed out since it was generated, then we reject the request.

1
<?php

2
if(!verify_nonce($_POST['nonce'])) {

3
header("HTTP/1.1 403 Forbidden", true, 403);

4
exit();

5
}

6
// proceed normally

7
?>

This protects us from the CSRF attack since the attacker’s website cannot generate our nonce.

If you don’t use a nonce, your user can be tricked into doing things they would not normally do. Note that even if you do use a nonce, you may still be susceptible to a click-jacking attack.

3. Click-jacking

While not on the OWASP top ten list for 2010, click-jacking has gained recent fame due to attacks against Twitter and Facebook, both of which spread very quickly due to the social nature of these platforms.

Now since we use a nonce, we’re protected against CSRF attacks, however, if the user is tricked into clicking the submit link themselves, then the nonce won’t protect us. In this kind of attack, the attacker includes our website in an iframe on their own website. The attacker doesn’t have control over our page, but they do control the iframe element. They use CSS to set the iframe’s opacity to 0, and then use JavaScript to move it around such that the submit button is always under the user’s mouse. This was the technique used on the Facebook Like button click-jack attack.

Frame busting appears to be the most obvious way to protect against this, however it isn’t fool proof. For example, adding the security="restricted" attribute to an iframe will stop any frame busting code from working in Internet Explorer, and there are ways to prevent frame busting in Firefox as well.

A better way might be to make your submit button disabled by default and then use JavaScript to enable it once you’ve determined that it’s safe to do so. In our example above, we’d have code like this:

1
<input type="text" name="message" value="<?php echo $message ?>">

2
<input id="msg_btn" type="submit" disabled="true">

3
<script type="text/javascript">

4
if(top == self) {

5
document.getElementById("msg_btn").disabled=false;

6
}

7
</script>

This way we ensure that the submit button cannot be clicked on unless our page runs in a top level window. Unfortunately, this also means that users with JavaScript disabled will also be unable to click the submit button.

4. SQL injection

In this kind of an attack, the attacker exploits insufficient input validation to gain shell access on your database server. XKCD has a humorous take on SQL injection:

Full image (from xkcd)

Let’s go back to the example we have above. In particular, let’s look at the save_message() function.

01
<?php

02
function save_message($user, $message)

03
{

04
$sql = "INSERT INTO Messages (

05
user, message

06
) VALUES (

07
'$user', '$message'

08
)";

09

10
return mysql_query($sql);

11
}

12
?>

The function is oversimplified here, but it exemplifies the problem. The attacker could enter something like

1
test');DROP TABLE Messages;--

When this gets passed to the database, it could end up dropping the Messages table, causing you and your users a lot of grief. This kind of an attack calls attention to the attacker, but little else. It’s far more likely for an attacker to use this kind of attack to insert spammy data on behalf of other users. Consider this message instead:

1
test'), ('user2', 'Cheap medicine at ...'), ('user3', 'Cheap medicine at ...

Here the attacker has successfully managed to insert spammy messages into the comment streams fromuser2 and user3 without needing access to their accounts. The attacker could also use this to download your entire user table that possibly includes usernames, passwords and email addresses.

Fortunately, we can use prepared statements to get around this problem. In PHP, the PDO abstraction layer makes it easy to use prepared statements even if your database itself doesn’t support them. We could change our code to use PDO.

01
<?php

02
function save_message($user, $message)

03
{

04
// $dbh is a global database handle

05
global $dbh;

06

07
$stmt = $dbh->prepare('

08
INSERT INTO Messages (

09
user, message

10
) VALUES (

11
?, ?

12
)');

13
return $stmt->execute(array($user, $message));

14
}

15
?>

This protects us from SQL injection by correctly making sure that everything in $user goes into the userfield and everything in $message goes into the message field even if it contains database meta characters.

There are cases where it’s hard to use prepared statements. For example, if you have a list of values in anIN clause. However, since our SQL statements are always generated by code, it is possible to first determine how many items need to go into the IN clause, and add as many ? placeholders instead.

5. Shell injection

Similar to SQL injection, the attacker tries to craft an input string to gain shell access to your web server. Once they have shell access, they could potentially do a lot more. Depending on access privileges, they could add JavaScript to your HTML pages, or gain access to other internal systems on your network.

Shell injection can take place whenever you pass untreated user input to the shell, for example by using the system(), exec() or `` commands. There may be more functions depending on the language you use when building your web app.

The solution is the same for XSS attacks. You need to validate and sanitize all user inputs appropriately for where it will be used. For data that gets written back into an HTML page, we use PHP’s input_filter()function with the FILTER_SANITIZE_SPECIAL_CHARS flag. For data that gets passed to the shell, we use the escapeshellcmd() and escapeshellarg() functions. It’s also a good idea to validate the input to make sure it only contains a whitelist of characters. Always use a whitelist instead of a blacklist. Attackers find inventive ways of getting around a blacklist.

If an attacker can gain shell access to your box, all bets are off. You may need to wipe everything off that box and reimage it. If any passwords or secret keys were stored on that box (in configuration files or source code), they will need to be changed at all locations where they are used. This could prove quite costly for your organization.

6. Phishing

Phishing is the process where an attacker tricks your users into handing over their login credentials. The attacker may create a page that looks exactly like your login page, and ask the user to log in there by sending them a link via e-mail, IM, Facebook, or something similar. Since the attacker’s page looks identical to yours, the user may enter their login credentials without realizing that they’re on a malicious site. The primary method to protect your users from phishing is user training, and there are a few things that you could do for this to be effective.

Always serve your login page over SSL. This requires more server resources, but it ensures that the user’s browser verifies that the page isn’t being redirected to a malicious site.
Use one and only one URL for user log in, and make it short and easy to recognize. For our example website, we could use https://login.mybiz.com as our login URL. It’s important that when the user sees a login form for our website, they also see this URL in the URL bar. That trains users to be suspicious of login forms on other URLs
Do not allow partners to ask your users for their credentials on your site. Instead, if partners need to pull user data from your site, provide them with an OAuth based API. This is also known as the Password Anti-Pattern.
Alternatively, you could use something like a sign-in image that some websites are starting to use (e.g. Bank of America, Yahoo!). This is an image that the user selects on your website, that only the user and your website know about. When the user sees this image on the login page, they know that this is the right page. Note that if you use a sign-in seal, you should also use frame busting to make sure an attacker cannot embed your sign-in image page in their phishing page using an iframe.

If a user is trained to hand over their password to anyone who asks for it, then their data isn’t safe.

Summary

While we’ve covered a lot in this article, it still only skims the surface of web application security. Any developer interested in building truly secure applications has to be on top of their game at all times. Stay up to date with various security related mailing lists, and make sure all developers on your team are clued in. Sometimes it may be necessary to sacrifice features for security, but the alternative is far scarier.

Finally, I’d like to thank the Yahoo! Paranoids for all their help in writing this article.

Criar traduções para extensões Joomla

Publicado em 06/05/201016/09/2015 por homdigitalis

How to create translation for Joomla! extensions

This article describes how to create translation for Joomla! specific extension. As example we will build Czech language for Phoca Gallery component.

1) We will prepare folder structure for the new created translation. Create the following folders on your disc:

lang/admin
lang/site

Open text editor and paste there the following content:

1
<html><body bgcolor="#FFFFFF"></body></html>

Save it as index.html in both folders (as lang/admin/index.html and lang/site/index.html).

2) Unzip the Phoca Gallery component ZIP file somewhere on your disc. Go to:

language/en-GB/ folder (which is included in the unzipped Phoca Gallery structure)

and open both files:

en-GB.com_phocagallery.ini
en-GB.com_phocagallery.menu.ini

in text editor. Translate the strings to your langauge and save them as (in our example we use Czech prefixes):

lang/admin/cs-CZ.com_phocagallery.ini
lang/admin/cs-CZ.com_phocagallery.menu.ini
lang/site/cs-CZ.com_phocagallery.ini
lang/site/cs-CZ.com_phocagallery.menu.ini

Files should be saved as UTF-8 without BOM encoding.

3) Open text editor and paste there the following content:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<install type="language" version="1.5" client="both" method="upgrade"> <name>cs-CZ.com_phocagallery</name> <tag>cs-CZ</tag> <creationDate>01/01/2009</creationDate> <author>Jan Pavelka</author> <authorEmail>info[at]phoca[dot]cz</authorEmail> <authorUrl>http://www.phoca.cz</authorUrl> <copyright>(C) 2008 Jan Pavelka</copyright> <license>http://www.gnu.org/licenses/gpl-2.0.html GNU/GPL </license> <description>Czech language pack for Phoca Gallery</description> <administration> <files folder="admin"> <filename>cs-CZ.com_phocagallery.ini</filename> <filename>cs-CZ.com_phocagallery.menu.ini</filename> <filename>index.html</filename> </files> </administration> <site> <files folder="site"> <filename>cs-CZ.com_phocagallery.ini</filename> <filename>cs-CZ.com_phocagallery.menu.ini</filename> <filename>index.html</filename> </files> </site> </install>

Edit it and ave it as :

lang/install.xml file.

So now you should have the following folder structure in the folder lang:

install.xml
admin/index.html
admin/cs-CZ.com_phocagallery.ini
admin/cs-CZ.com_phocagallery.menu.ini
site/index.html
site/cs-CZ.com_phocagallery.ini
site/cs-CZ.com_phocagallery.menu.ini

Select all files included in lang folder and add them into ZIP file called lang-prefix-LANG-PREFIX.com_phocagallery.zip (in our example the file will have the following name: cs-CZ.com_phocagallery.zip)

Now the translation is ready and can be installed via standard Joomla! installation procedure.

Directrizes de Projecto – proteger aplicativos Web

Publicado em 26/04/201016/09/2015 por homdigitalis

Os aplicativos da Web apresentam um conjunto complexo de questões de segurança para arquitetos, designers e desenvolvedores. Os aplicativos da Web mais seguros e resistentes a ataques são aqueles que foram criados com o requisito segurança em primeiro lugar.

Você deve aplicar práticas de arquitetura e design e incorporar considerações de implantação e diretivas de segurança corporativas durante as fases iniciais do projeto. Se isso não for feito, poderá resultar em aplicativos que não podem ser implantados numa infra–estrutura existente sem comprometer a segurança.
Este módulo apresenta um conjunto de diretrizes de segurança para projeto e arquitetura. Ele foi organizado por categoria de vulnerabilidade dos aplicativos comuns. São as áreas principais de segurança dos aplicativos da Web e são as mesmas onde os erros ocorrem com mais frequência.

Objetivos

Utilize este módulo para:

• Identificar as questões principais de projeto e arquitetura de aplicativos da Web seguros.
• Considerar as principais questões de implantação no momento do projeto.
• Projetar estratégias para melhorar a validação da entrada do aplicativo da Web.
• Criar mecanismos seguros de autenticação e gerenciamento de sessões.
• Escolher um modelo de autorização apropriado.
• Implementar práticas eficientes de gerenciamento de contas e proteger as sessões dos usuários.
• Utilizar criptografia para oferecer privacidade, não–recusa, proteção contra violações e autenticação.
• Evitar a manipulação de parâmetros.
• Criar estratégias de auditoria e log.

Aplicação

Embora contidas no livro sobre segurança ASP.NET, as informações deste módulo são importantes para qualquer pessoa interessada em desenvolver aplicativos da Web seguros.

Como utilizar este módulo

O foco deste módulo está nas diretrizes e nos princípios que você deve seguir ao projetar um aplicativo.

Para aproveitar ao máximo este módulo:

• Conheça as ameaças ao seu aplicativo para que você possa garantir que isso seja solucionado pelo seu projeto.
Leia, “Ameaças e Contramedidas”, para entender as ameaças a considerar. O módulo 2 relaciona as ameaças que podem prejudicar seu aplicativo. Considere essas ameaças durante a fase de projeto.
• Use uma abordagem sistemática para as áreas principais nas quais o aplicativo poderia ficar vulnerável a ataques. Pontos nos quais se concentrar: considerações sobre a implantação; validação da entrada; autenticação e autorização; criptografia e confidencialidade dos dados; gerenciamento de configuração, sessões e exceções e auditoria e log adequados para garantir a criação de contas.

Questões de arquitetura e projeto para aplicativos da Web

Os aplicativos da Web apresentam a designers e desenvolvedores muitos desafios. Como o protocolo HTTP não mantém um registro das sessões por usuário, o registro passa a ser de responsabilidade do aplicativo. Como precursor disso, o aplicativo deve ser capaz de identificar o usuário utilizando alguma forma de autenticação. Como todas as decisões subseqüentes de autorização baseiam–se na identidade do usuário, é essencial que o processo de autenticação seja seguro e que o mecanismo de tratamento da sessão utilizado para monitorar os usuários autenticados seja igualmente bem protegido. Projetar os mecanismos de autenticação seguros e o gerenciamento de sessão é apenas parte das questões com que se deparam designers e desenvolvedores de aplicativos da Web. Outros desafios surgem porque a entrada e a saída de dados são feitos por redes públicas. Impedir a manipulação de parâmetros e a divulgação de dados confidenciais é outra questão importante.

As diretrizes de projeto apresentadas neste módulo estão organizadas por categoria de vulnerabilidade do aplicativo. A experiência mostra que um projeto deficiente nessas áreas em particular cria vulnerabilidades de segurança.

Vulnerabilidades do aplicativo da Web e possíveis problemas causados por um projeto ruim

Categoria da vulnerabilidade e possível problema causado por um projeto ruim

Validação da entrada Ataques realizados incorporando–se sequências de caracteres mal–intencionadas em sequências de caracteres de consulta, campos de formulário, cookies e cabeçalhos HTTP. Eles incluem execução de comandos, ataques XSS (cross-site scripting), inclusão de código SQL e estouro de buffer.

Autenticação Spoofing de identidade, quebra de senha, elevação de privilégios e acesso não–autorizado.

Autorização Acesso a dados confidenciais ou restritos, violação e execução de operações não–autorizadas.

Gerenciamento de configuração Acesso não–autorizado a interfaces administrativas, capacidade de atualizar dados de configuração e acesso não–autorizado a contas de usuários e perfis de contas.

Dados confidenciais Informações confidenciais divulgadas e violação de dados.

Gerenciamento de sessão Captura de identificadores de sessão, resultando em sequestro de sessão e spoofing de identidade.

Criptografia Acesso a dados confidenciais, a credenciais de contas ou a ambos.

Manipulação de parâmetros Ataques de atravessamento de caminho, execução de comando e mecanismos para ignorar o controle de acesso, entre outros, levando à divulgação de informações ,elevação de privilégios e negação de serviço.

Gerenciamento de exceções Negação de serviço e divulgação de detalhes confidenciais do sistema.

Auditoria e log Falha ao indicar sinais de invasão, incapacidade de comprovar as ações de um usuário e dificuldades no diagnóstico de problemas.

Considerações para implantação

Durante a fase de design do aplicativo, analise as diretivas e os procedimentos da empresa junto a infra–estrutura na qual seu aplicativo será implantado. Freqüentemente, o ambiente de destino é rígido e o projeto do aplicativo deve refletir as restrições. Às vezes, são necessárias mudanças no projeto, por exemplo, devido a restrições de protocolo ou porta ou topologias de implantação específicas. Identifique as restrições no início da fase de projeto para evitar surpresas mais tarde e envolver membros das equipes de rede e infra–estrutura para ajudarem nesse processo.

Políticas e procedimentos de segurança

A diretiva de segurança determina o que os aplicativos podem fazer e o que os usuários do aplicativo têm permissão para fazer. O mais importante: ela define restrições para determinar o que os aplicativos e os usuários não podem fazer. Identifique e trabalhe com a estrutura definida pela diretiva de segurança da empresa ao projetar os aplicativos para garantir que você não está violando a diretiva, o que impedirá a implantação do aplicativo.

Componentes da infra–estrutura de rede

Certifique–se de que você entendeu a estrutura de rede do ambiente de destino e os requisitos básicos de segurança da rede em termos de regras de filtragem, restrições de porta, protocolos suportados e assim por diante.
Identifique como firewalls e suas diretivas podem afetar o projeto e a implantação do aplicativo. Pode haver firewalls para separar da rede interna os aplicativos ligados diretamente à Internet. Pode haver firewalls adicionais do banco de dados. Eles podem afetar as portas de comunicação possíveis e, portanto, as opções de autenticação do servidor Web para servidores de aplicativos e de banco de dados remotos. Por exemplo, a autenticação do Windows requer portas adicionais.
Na fase de projeto, considere quais protocolos, portas e serviços podem acessar os recursos internos a partir de servidores Web localizados na rede de perímetro. Identifique também os protocolos e as portas necessários ao projeto do aplicativo e analise as ameaças que podem surgir com a abertura de novas portas ou com o uso de novos protocolos.
Comunique e registre qualquer consideração sobre a segurança na camada da rede e do aplicativo e qual componente cuidará disso. Isso evita que faltem controles de segurança quando as equipes de desenvolvimento e de rede assumirem que a outra equipe está cuidado do assunto. Preste atenção às defesas de segurança que o aplicativo espera que a rede forneça. Considere as implicações de uma alteração na configuração da rede. Quanto você perderá de segurança se implementar uma alteração específica na rede?

Topologias de implantação

A topologia de implantação do aplicativo e se existe uma camada de aplicativo remota são considerações importantes a serem incorporadas ao seu projeto. Se existir uma camada de aplicativo remota, você terá que considerar como proteger a rede entre os servidores para eliminar a ameaça de espionagem da rede e para fornecer privacidade e integridade aos dados confidenciais.

Considere também identificar o fluxo e as contas que serão utilizadas para autenticação da rede quando o aplicativo conectar–se com servidores remotos. Uma abordagem comum é utilizar pelo menos uma conta de processo privilegiada e criar uma conta duplicada (espelho) no servidor remoto com a mesma senha. Como alternativa, convém utilizar uma conta de processo de domínio, que facilita a administração, mas é mais problemática de proteger devido à dificuldade de limitar o uso da conta pela rede. Um firewall intermediário ou domínios separados sem relações de confiança geralmente fazem com que a abordagem de conta local seja a única opção viável.

Intranet, extranet e Internet

Cada um desses cenários de uso do aplicativo apresenta desafios de projeto. As questões a considerar incluem: Como você conduzirá a identidade do chamador em várias camadas de aplicativo até os recursos back–end? Onde será feita a autenticação? Você pode confiar na autenticação feita no front–end e então utilizar uma conexão confiável para acessar recursos de back–end? No caso da extranet, você também deve considerar se confia nas contas dos parceiros.
Para obter mais informações sobre questões específicas para esses e outros cenários, consulte as seções “Intranet Security”, “Extranet Security” e “Internet Security” de “Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication” em [url=”http://msdn.microsoft.com/library/en-us/dn…ecnetlpMSDN.asp”%5Dhttp://msdn.microsoft.com/library/en-us/dn…ecnetlpMSDN.asp%5B/url%5D (em inglês).

Validação da entrada

A validação da entrada é um desafio e o peso de uma solução cai sobre os ombros dos desenvolvedores do aplicativo. No entanto, a validação da entrada correta é uma das medidas de defesa mais fortes contra os ataques a aplicativos realizados atualmente. A validação da entrada correta é uma contramedida eficiente que pode ajudar a impedir ataques de scripts em sites, inclusão de código SQL e estouro do buffer, entre outros ataques de entrada.
A validação da entrada é difícil porque não há uma resposta única a o que constitui uma entrada válida entre os aplicativos e nem mesmo em cada aplicativo. Da mesma forma, não há uma única definição de entrada mal–intencionada. Além disso, o que o aplicativo faz com essa entrada influencia o risco de exploração. Por exemplo, você armazena dados para serem utilizados por outros aplicativos ou o seu aplicativo usa a entrada feita em outras fontes de dados por outros aplicativos?

As práticas a seguir melhoram a validação da entrada do aplicativo da Web:

• Considere que todas as entradas são mal–intencionadas.
• Centralize a sua abordagem.
• Não confie na validação do lado do cliente.
• Tenha cuidado com questões de canonização.
• Restrinja, rejeite e limpe a entrada.

Considere que todas as entradas são mal–intencionadas

A validação da entrada começa com a suposição fundamental de que toda entrada é mal–intencionada até que se prove o contrário. Independentemente de a entrada ter origem em um serviço, um compartilhamento de arquivo, um usuário ou de um banco de dados, valide a entrada se a fonte estiver fora do limite confiável. Por exemplo, se você chamar um Web Service externo que retornar seqüências de caracteres, como você sabe se não foram inseridos comandos mal–intencionados? Além disso, se houver vários aplicativos gravando dados em um banco de dados compartilhado, ao ler os dados, como saber se eles são seguros?

Centralize a sua abordagem

Faça da estratégia de validação da entrada um elemento básico do projeto do aplicativo. Considere uma abordagem centralizada para validação, por exemplo, utilizando um código comum de validação e filtragem em bibliotecas compartilhadas. Isso garante que as regras de validação serão aplicadas de forma consistente. Isso também reduz o trabalho de desenvolvimento e ajuda na manutenção futura.
Em muitos casos, campos individuais requerem validação específica, por exemplo, com expressões regulares desenvolvidas especialmente. No entanto, você pode freqüentemente melhorar rotinas comuns para validar campos utilizados regularmente, como endereços de email, cargos, nomes, endereços postais (incluindo CEP) e assim por diante.

Não confie na validação do lado do cliente

O código do lado do servidor deve executar sua própria validação. E se um invasor ignorar ou desativar as rotinas de script do lado do cliente, por exemplo, desativando o JavaScript? Use validação no lado do cliente para ajudar a reduzir o número de idas e vindas ao servidor, mas não confie nela para a segurança. Esse é um exemplo de defesa profunda.

Tenha cuidado com questões de canonização

Dados em forma canônica estão na sua forma padrão ou mais simples. Canonização é o processo de converter dados em sua forma canônica. Caminhos de arquivo e URLs são particularmente sujeitos a problemas de canonização e exploração bem conhecidas são o resultado direto de bugs de canonização. Por exemplo, considere a seqüência de caracteres a seguir que contém um arquivo e o caminho em sua forma canônica.

c:\temp\algumarquivo.dat

As seqüências de caracteres a seguir também poderiam representar o mesmo arquivo.
algumarquivo.dat

c:\temp\subdir\..\algumarquivo.dat
c:\ temp\ algumarquivo.dat
..\algumarquivo.dat
c%3A%5Ctemp%5Csubdir%5C%2E%2E%5Calgumarquivo.dat

No último exemplo, os caracteres foram especificados na forma hexadecimal:

• %3A representa o sinal dois–pontos.
• %5C representa uma barra invertida.
• %2E representa um ponto.

Geralmente, você deve tentar evitar projetar aplicativos que aceitam nomes de arquivo na entrada do usuário para evitar problemas de canonização. Em vez disso, considere projetos alternativos. Por exemplo, deixe o aplicativo determinar o nome do arquivo para o usuário.

Se você aceitar nomes de arquivo na entrada, certifique–se de que eles estejam estritamente formados antes de tomar decisões de segurança como autorizar ou negar acesso ao arquivo especificado.

Restrinja, rejeite e limpe a entrada

A melhor abordagem para validar a entrada é restringir desde o começo o que será permitido. É muito mais fácil validar dados de tipos, padrões e intervalos conhecidos que validá–los procurando caracteres inválidos conhecidos. Quando você projeta o aplicativo, sabe o que ele espera. O intervalo de dados válidos geralmente é um conjunto mais finito que o de entradas mal–intencionadas possíveis. No entanto, para uma defesa mais detalhada, convém rejeitar a entrada inválida conhecida e então limpá–la.

Para criar uma estratégia de validação da entrada eficiente, conheça as abordagens a seguir e suas exigências:

• Restringir a entrada.
• Validar dados por tipo, tamanho, formato e intervalo.
• Rejeitar dados inválidos.
• Limpar a entrada.

Restringir a entrada

Restringir a entrada refere–se a aceitar dados bons. Esta é a melhor abordagem. A idéia é definir um filtro de entradas aceitáveis utilizando tipo, tamanho, formato e intervalo. Defina o que é uma entrada aceitável para os campos do aplicativo e a aplique. Rejeite o restante como dados inválidos.
A restrição da entrada deve envolver a definição de conjuntos de caracteres no servidor para que você possa estabelecer a forma canônica da entrada de maneira localizada.

Validar os dados por tipo, tamanho, formato e intervalo

Use uma verificação de tipo rígida da entrada de dados sempre que possível, por exemplo, em classes utilizadas para manipular e processar os dados da entrada e em rotinas de acesso a dados. A exemplo disto, utilize procedimentos armazenados com parâmetros para acessar dados a fim de aproveitar a verificação de tipo dos campos de entrada.
Verifique também os campos de seqüências de caracteres e, muitas vezes, se seu formato é apropriado. Por exemplo, CEPs, números de RG, etc. têm formatos definidos que podem ser validados utilizando–se expressões regulares. A verificação completa não é a única boa prática de programação; ela dificulta que um invasor explore o código. O invasor pode passar pela verificação de tipo, mas a verificação de tamanho pode dificultar a execução de seu ataque favorito.

Rejeitar dados inválidos

Rejeite dados “inválidos”, mas não dependa totalmente dessa abordagem. Geralmente, ela é menos eficiente que utilizar a abordagem de “permissão” descrita anteriormente e é melhor usá–la de forma combinada. Para negar dados inválidos, assume–se que o aplicativo conhece todas as variações de uma entrada mal–intencionada. Lembre–se de que existem várias formas de representar caracteres. Esse é um outro motivo pelo qual a “permissão” é a abordagem preferida.
Embora seja útil para aplicativos que já estão em uso e quando você não pode arcar com alterações significativas, a abordagem de “negação” não é tão robusta como a de “permissão” pode os dados inválidos, como padrões que podem ser utilizados para identificar ataques comuns, não são constantes. Os dados válidos são constantes enquanto os dados inválidos podem variar periodicamente.

Limpar a entrada

Quando falamos em limpeza, significa transformar dados possivelmente mal–intencionados em dados seguros. Isso pode ser útil quando o intervalo de entrada permitido não pode garantir que a entrada é segura. Isso inclui qualquer coisa desde separar um valor nulo do final de uma seqüência de caracteres fornecida pelo usuário até remover valores para que sejam tratados como literais.
Outro exemplo comum de limpeza da entrada de aplicativos da Web é utilizar codificação de URL ou HTML para combinar dados e tratá–los como texto literal em vez de como script executável. Os métodos de HtmlEncode removem caracteres HTML e UrlEncode codificam um URL para que ele seja uma solicitação URI válida.

Na prática

Seguem exemplos aplicados a campos de entrada comuns utilizando as abordagens citadas:

• Campo Sobrenome. Este é um bom exemplo de onde a restrição da entrada é apropriada. Nesse caso, convém restringir os dados da seqüência de caracteres no intervalo ASCII A–Z e a–z e também em hífens e apóstrofes (apóstrofes não significam nada para o SQL) para tratar nomes como O’Dell. Também é ideal limitar a extensão ao maior valor esperado.
• Campo Quantidade. Este é outro caso em que a restrição da entrada funciona bem. Neste exemplo, convém utilizar uma restrição simples de tipo e intervalo. Por exemplo, os dados da entrada podem precisar ser um número inteiro positivo entre 0 e 1000.
• Campo Texto livre. Os exemplos incluem campos de comentário em quadros de discussão. Nesse caso, convém permitir o uso de letras e espaços além de caracteres comuns, como apóstrofes, vírgulas e hífens. O conjunto do que é permitido não inclui sinais de maior que e menor que, chaves e colchetes.
Alguns aplicativos podem permitir que os usuários marquem o texto utilizando um conjunto finito de caracteres de script, como negrito “” e itálico ““, ou até mesmo incluam um link para o URL favorito. No caso de um URL, a validação deve codificar o valor para que ele seja tratado como URL.

Um aplicativo da Web existente que não valida a entrada do usuário. Em um cenário ideal, o aplicativo verifica se a entrada de cada campo ou ponto de entrada é aceitável. No entanto, se você já possui um aplicativo da Web que não valida a entrada do usuário, você precisa de uma abordagem “quebra galho” para reduzir o risco até que seja possível aprimorar a estratégia de validação da entrada do aplicativo. Embora nenhuma das abordagens a seguir garantam um tratamento seguro da entrada, pois dependem de fatores como de onde vem a entrada e como ela será utilizada no aplicativo, elas são empregadas atualmente como correções rápidas para melhorar a segurança em curto prazo:

• Codificar como HTML e URL a entrada do usuário ao gravar de volta no cliente. Nesse caso, considera–se que nenhuma entrada é tratada como HTML e todas as saída são gravadas de volta de forma protegida. Essa é uma ação de limpeza.
• Rejeitar caracteres de script mal-intencionados. Esse é um caso de rejeição de entrada inválida conhecida. Nesse caso, um conjunto configurável de caracteres mal–intencionados é utilizado para rejeitar a entrada. Como descrito anteriormente, o problema dessa abordagem é um dado considerado inválido de acordo com o contexto.

Autenticação

Autenticação é o processo pelo qual se determina a identidade do chamador. Existem três aspectos a considerar:

• Identificar onde a autenticação é necessária no aplicativo. Geralmente, ela é requerida sempre que um limite confiável é ultrapassado. Os limites confiáveis normalmente incluem conjuntos, processos e hosts.
• Validar quem é o chamador. Os usuários geralmente se autenticam com nomes de usuário e senhas.
• Identificar o usuário nas solicitações subseqüentes. Isso requer alguma forma de identificador de autenticação.
Muitos aplicativos da Web usam um mecanismo de senha para autenticar usuários, sendo que o usuário fornece um nome de usuário e uma senha em formato HTML. As questões a considerar nesse caso incluem:
• Os nomes de usuário e senhas são enviados em texto sem formatação por um canal inseguro? Se sim, um invasor pode utilizar um software de monitoramento de rede para espionar e capturar as credenciais. A contramedida aqui é proteger o canal de comunicação utilizando SSL (Secure Socket Layer).
• Como as credenciais são armazenadas? Se você estiver armazenando nomes de usuário e senhas em texto sem formatação, em arquivos ou em um banco de dados, está procurando problemas. E se o diretório do aplicativo não estiver configurado corretamente e um invasor procurar um arquivo e baixar seu conteúdo ou incluir uma conta de logon com privilégios? E se um administrador descontente levar seu banco de dados de nomes de usuário e senhas?
• Como as credenciais são verificadas? Não é necessário armazenar senhas de usuário se a única finalidade for verificar se o usuário conhece a senha. Em vez disso, você pode armazenar um verificador na forma de um valor de hash e recalcular o hash utilizando o valor fornecido pelo usuário durante o processo de logon. Para eliminar a ameaça de um ataque de dicionário contra o armazenamento de credenciais, utilize senhas de alta segurança e combine um valor falso gerado aleatoriamente com o hash da senha.
• Como o usuário autenticado é identificado após o logon inicial? É necessária alguma forma de permissão de autenticação como, por exemplo, um cookie de autenticação. Como o cookie é protegido? Se ele for enviado por um canal desprotegido, um invasor pode capturá–lo e usá–lo para acessar o aplicativo. Um cookie de autenticação roubado é um logon roubado.

As práticas a seguir melhoram a autenticação do aplicativo da Web:

• Separar áreas públicas e restritas.
• Utilizar diretivas de bloqueio de conta para as contas de usuário final.
• Utilizar senhas com data de validade.
• Poder desativar contas.
• Não armazenar senhas nos armazenamentos de usuários.
• Exigir senhas de alta segurança.
• Não transmitir senhas em texto sem formatação.
• Proteger os cookies de autenticação.

Separar áreas públicas e restritas

A área pública do seu site pode ser acessada por qualquer usuário de forma anônima. As áreas restritas só podem ser acessadas por pessoas específicas e os usuários devem ser autenticados no site. Considere um site comum de uma loja. Você pode navegar pelo catálogo de produtos de forma anônima. Quando você inclui itens no carrinho de compra, o aplicativo identifica você utilizando um identificador de sessão. Finalmente, quando você faz o pedido, realiza uma transação segura. Nesse ponto, você precisa fazer logon para autenticar sua transação pela SSL.
Dividindo o site em áreas de acesso pública e restrita, você pode aplicar regras de autenticação e autorização a todo o site e limitar o uso da SSL. Para evitar a sobrecarga desnecessária sobre o desempenho provocado pela SSL, projete o site de modo a limitar o uso da SSL nas áreas que requerem acesso autenticado.
Utilizar diretivas de bloqueio de conta para as contas de usuário final

Desative contas de usuário final ou a gravação de eventos em log depois de um número determinado de tentativas de logon sem sucesso. Se você estiver utilizando a autenticação do Windows, como NTLM ou o protocolo Kerberos, essas diretivas podem ser configuradas e aplicadas automaticamente pelo sistema operacional. Com autenticação de formulários, essas diretivas são responsabilidade do aplicativo e devem ser incorporadas ao projeto do mesmo.
Tenha cuidado para que as diretivas de bloqueio de contas não sejam utilizadas em ataques de negação de serviço. Por exemplo, contas de serviço padrão conhecidas, como IUSR_MACHINENAME, devem ser substituída por nomes de contas personalizados para evitar que um invasor que consiga obter o nome do servidor Web do IIS (Internet Information Services) bloqueie essa conta vital.

Utilizar senhas com data de validade

As senhas não devem ser estáticas e sim alteradas como parte da rotina de manutenção de senha por meio de períodos de validade da senha. Considere fornecer esse tipo de recurso ao projetar o aplicativo.

Poder desativar contas

Se o sistema estiver comprometido, poder invalidar deliberadamente credenciais ou desativar contas pode evitar outros ataques.

Não registrar senhas nos armazenamentos de usuários

Se você deve verificar as senhas, não é necessário realmente armazená–las. Em vez disso, armazene um valor de hash unidirecional e então recalcule o hash utilizando as senhas fornecidas pelos usuários. Para eliminar a ameaça de um ataque de dicionário contra o armazenamento do usuário, utilize senhas de alta segurança e incorpore um valor falso gerado com a senha.

Exigir senhas de alta segurança

Não facilite a quebra de senhas para os invasores. Existem muitas instruções, mas uma prática geral é exigir no mínimo oito caracteres e uma mistura de letras maiúsculas e minúsculas, números e caracteres especiais. Tanto se você estiver utilizando uma plataforma para aplicar essas regras ou quanto se estiver desenvolvendo sua própria validação, essa etapa é necessária para combater ataques de força bruta, nos quais o invasor tenta quebrar uma senha sistematicamente por tentativa e erro. Utilize expressões regulares para ajudar na validação de senhas de alta segurança.

Não transmitir senhas em texto sem formatação

Senhas em texto sem formatação enviadas por uma rede ficam vulneráveis à espionagem. Para acabar com essa ameaça, você precisa proteger o canal de comunicação como, por exemplo, utilizar SSL para criptografar o tráfego.

Proteger os cookies de autenticação

Um cookie de autenticação roubado é um logon roubado. Proteja as permissões de autenticação utilizando criptografia e canais de comunicação seguros. Além disso, limite o tempo de validade de uma permissão de autenticação para combater a ameaça de spoofing que pode resultar de ataques de repetição, nos quais o invasor captura o cookie e o usa para obter acesso ilegal ao site. Reduzir o tempo limite do cookie não evita ataques de repetição, mas limita o tempo pelo qual o invasor terá acesso ao site utilizando o cookie roubado.

Autorização

A autorização determina o que a identidade autenticada pode realizar e quais recursos ela acessa. Uma autorização incorreta ou ineficaz leva à divulgação de informações e à violação dos dados. Defesa profunda é o princípio básico de segurança utilizado na estratégia de autorização do aplicativo.

As práticas a seguir melhoram a autorização do aplicativo da Web:

• Utilizar vários gatekeepers.
• Restringir o acesso do usuário a recursos no nível do sistema.
• Considerar a granulação da autorização.

Utilizar vários gatekeepers

No lado do servidor, você pode utilizar as diretivas do IPSec (IP Security Protocol) para definir restrições do host a fim de restringir a comunicação entre servidores. Por exemplo: uma diretiva IPSec poderia restringir a conexão de qualquer host separado de um servidor Web com um servidor de banco de dados. O IIS fornece permissões da Web e restrições IP/DNS (Internet Protocol/Domain Name System). As permissões da Web do IIS são válidas para todos os recursos solicitados pelo HTTP independentemente do usuário. Elas não oferecem proteção se um invasor tiver como realizar logon no servidor. Por isso, as permissões de NTFS consentem que você especifique listas de controle de acesso por usuário. Finalmente, o ASP.NET fornece autorização de URL e de arquivo junto a demanda de permissão principal. Combinando esses gatekeepers, você pode desenvolver uma estratégia de autorização eficiente.

Restringir o acesso do usuário a recursos no nível do sistema

Os recursos no nível do sistema incluem arquivos, pastas, chaves do registro, objetos do Active Directory, objetos do banco de dados, logs de evento, etc. Utilize as listas de controle de acesso do Windows para restringir quais usuários podem acessar quais recursos e os tipos de operação que eles podem executar. Preste atenção especialmente nas contas de usuário anônimas da Internet; utilize as listas de controle de acesso para restringi–las a recursos que negam acesso explicitamente a usuários anônimos.

Considerar a granulação da autorização

Existem três modelos comuns de autorização, cada um com graus diferentes de granulação e escalabilidade.
A abordagem mais granular depende de representação. O acesso aos recursos ocorre utilizando o contexto de segurança do chamador. As listas de controle de acesso do Windows dos recursos protegidos (geralmente arquivos ou tabelas, ou ambos) determinam se o chamador pode acessar o recurso. Se o aplicativo fornecer acesso basicamente a recursos específicos do usuário, essa abordagem pode ser válida. Sua vantagem é que a auditoria no nível do sistema operacional pode ser feita entre as camadas do aplicativo, pois o contexto de segurança do chamador original flui no nível do sistema operacional e é utilizado para acessar recursos. No entanto, seu problema é a escalabilidade do aplicativo, pois não é possível estabelecer um pool de conexão eficiente para acessar o banco de dados. Como resultado, essa abordagem é encontrada com mais freqüência em aplicativos para intranet de escala limitada.

A abordagem menos granular, porém mais escalonável, utiliza a identificação de processo do aplicativo para acessar recursos. Ela oferece suporte ao pool de conexão ao banco de dados, mas isso significa que as permissões concedidas à identificação do aplicativo no banco de dados são comuns, independentemente da identificação do chamador original. A autorização principal é feita na camada intermediária lógica do aplicativo utilizando funções, agrupando usuários que compartilham os mesmos privilégios com relação ao aplicativo. O acesso a classes e métodos é restringido de acordo com a participação do chamador na função. Para oferecer suporte à recuperação de dados por usuário, uma abordagem comum é inclui uma coluna de identificação nas tabelas do banco de dados e utilizar parâmetros de consulta para restringir os dados recuperados. Por exemplo: você pode passar a identificação do chamador original para o banco de dados no nível do aplicativo (não do sistema operacional) por meio de parâmetros de procedimentos armazenados e gravar consultas semelhantes a estas:

SELECT field1, field2, field3 FROM Table1 WHERE {some search criteria} AND

UserName = @originalCallerUserName

Esse modelo é conhecido como subsistema confiável ou, às vezes, como modelo de servidor confiável.
A terceira opção é utilizar um conjunto limitado de identidades para acessar recursos com base na participação do chamador na função. Na verdade, trata–se de um híbrido dos dois modelos descritos anteriormente. Os chamadores são mapeados para funções na camada intermediária lógica do aplicativo e o acesso a classes e métodos é restrito de acordo com a participação na função. O acesso a recursos de downstream é feito utilizando um conjunto restrito de identidade determinado pela participação na função do chamador atual. A vantagem dessa abordagem é que as permissões podem ser atribuídas a logons separados no banco de dados e a regulagem da conexão ainda ser efetiva com diversos pools de conexões. A desvantagem é que a criação dos símbolos de acesso com vários segmentos utilizados para estabelecer contextos diferentes de segurança para acessar recursos de downstream utilizando a autenticação do Windows é uma operação com privilégios que requer contas de processo com privilégios. Isso vai contra o princípio de menos privilégios.

Gerenciamento de configuração

Considere atentamente a funcionalidade de gerenciamento de configuração do aplicativo da Web. A maioria dos aplicativos requer interfaces que permitem que desenvolvedores de conteúdo, operadores e administradores configurem o aplicativo e gerenciem itens como conteúdo de páginas da Web, contas de usuário, informações do perfil do usuário e seqüências de caracteres para conexão do banco de dados. Se houver suporte para administração remota, como as interfaces de administração são protegidas? As conseqüências de uma falha de segurança em uma interface administrativa podem ser graves, pois o invasor freqüentemente acaba utilizando privilégios de administrador e tem acesso direto a todo o site.

As práticas a seguir aumentam a segurança do gerenciamento da configuração do aplicativo da Web:

• Proteger as interfaces administrativas.
• Proteger o armazenamento da configuração.
• Manter privilégios administrativos distintos.
• Utilizar contas com processos e serviços com a menor quantidade de privilégios.

Proteger as interfaces administrativas

É importante que a funcionalidade de gerenciamento da configuração seja acessível somente por operadores e administradores autorizados. O principal é aplicar uma autenticação rígida nas interfaces administrativas, por exemplo, utilizando certificados.

Se possível, limite ou evite o uso da administração remota e exija que os administradores façam logon localmente. Se você precisar oferecer suporte a administração remota, use canais criptografados, por exemplo, com tecnologia de SSL VPN, devido à natureza confidencial dos dados transmitidos pelas interfaces administrativas. Considere também limitar a administração remota a computadores da rede interna utilizando diretivas IPSec para diminuir ainda mais o risco.

Proteger o armazenamento da configuração

Arquivos de configuração em texto, o registro e os bancos de dados são as opções comuns para armazenamento dos dados de configuração do aplicativo. Se possível, evitar utilizar arquivos de configuração no espaço da Web do aplicativo para evitar possíveis vulnerabilidades no servidor de configuração, resultando no download dos arquivos de configuração. Independentemente da abordagem utilizada, proteja o acesso ao armazenamento da configuração, por exemplo, utilizando as listas de controle de acesso do Windows ou permissões do banco de dados. Além disso, evite armazenar informações confidenciais, como seqüências de caracteres de conexão do banco de dados ou credenciais de contas, em texto sem formatação. Proteja esses itens utilizando criptografia e restrinja o acesso à chave do registro, ao arquivo ou à tabela que contém os dados criptografados.

Manter privilégios administrativos distintos

Se a funcionalidade suportada pelos recursos do gerenciamento da configuração do aplicativo varia de acordo com a função do administrador, considere autorizar cada função separadamente utilizando a autorização com base na função. Por exemplo: a pessoa responsável por atualizar o conteúdo estático do site não precisa ter permissão para alterar o limite de crédito de um cliente.
Utilizar contas com processos e serviços com a menor quantidade de privilégios
Um aspecto importante da configuração do aplicativo são as contas de processo utilizadas para executar processos no servidor Web e as contas de serviço utilizadas para acessar recursos de downstream e sistemas. Certifique–se de que essas contas estejam configuradas com a menor quantidade de privilégios. Se um invasor conseguir assumir o controle de um processo, a identificação do processo deve ter acesso extremamente restrito ao sistema de arquivos e a outros recursos do sistema para limitar os danos que podem ser causados

Dados confidenciais

Os aplicativos que lidam com informações particulares dos usuários, como números de cartão de crédito, endereços, registros médicos e outros, devem seguir etapas especiais para garantir que os dados permanecerão particulares e inalterados. Além disso, os segredos utilizados na implementação do aplicativo, como senhas e seqüências de conexão ao banco de dados, devem ser protegidos. A segurança de dados confidenciais é um problema enquanto os dados são armazenados em um local de armazenamento persistente e enquanto são transmitidos pela rede.

Segredos

Os segredos incluem senhas, seqüências de caracteres de conexão ao banco de dados e números de cartão de crédito. As práticas a seguir aumentam a segurança do tratamento dos segredos feito pelo aplicativo da Web:

• Não armazenar segredos se for possível evitar.
• Não armazenar segredos no código.
• Não armazenar conexões ao banco de dados, senhas ou chaves em texto sem formatação.
• Evitar armazenar segredos na LSA (autoridade de segurança local).
• Utilizar a DAPI (API de Proteção a Dados) para criptografar os segredos.

Não armazenar segredos se for possível evitar

Armazenar segredos em software de maneira totalmente segura é impossível. Um administrador, com acesso físico ao servidor, pode acessar os dados. Não é necessário armazenar um segredo quando tudo o que você precisa fazer é verificar se o usuário o conhece. Nesse caso, você pode armazenar um valor de hash que representa o segredo e calcula o hash utilizando o valor fornecido pelo usuário para verificar se o usuário conhece o segredo.

Não armazenar segredos no código

Não inclua os segredos no código. Mesmo que o código–fonte não seja exposto no servidor Web, é possível extrair constantes de seqüências de caracteres de arquivos executáveis compilados. Uma vulnerabilidade na configuração pode permitir que um invasor recupere o executável.
Não armazenar conexões ao banco de dados, senhas ou chaves em texto sem formatação
Evite armazenar segredos como seqüências de caracteres de conexões ao banco de dados, senhas ou chaves em texto sem formatação. Utilize criptografia e armazene seqüências de caracteres criptografadas.

Evitar armazenar segredos na LSA

Evitar a LSA porque o aplicativo requer privilégios administrativos para acessá–la. Isso viola o princípio de segurança básico de utilizar a menor quantidade de privilégios. Além disso, a LSA pode armazenar segredos somente em um número restrito de slots. O melhor é utilizar a DPAPI, disponível no Microsoft Windows® 2000 e nos sistemas operacionais posteriores.

Utilizar DPAPI para criptografar os segredos

Para armazenar segredos como seqüências de caracteres de conexão a banco de dados ou credenciais de serviço das contas, use DPAPI. A principal vantagem de utilizar a DPAPI é que o sistema da plataforma gerencia a chave de criptografia/descriptografia e isso não é problema para o aplicativo. A chave é vinculada a uma conta de usuário do Windows ou a um computador específico, dependendo dos sinalizadores passados para as funções da DPAPI.
A DPAPI é mais adequada para criptografar informações, pois pode ser recriada manualmente em caso de perda das chaves mestre, por exemplo, devido a um dano no servidor que exija a reinstalação do sistema operacional. Dados que não podem ser recuperados porque você conhece o valor sem formatação, por exemplo, detalhes do cartão de crédito do cliente, requerem uma abordagem alternativa que usa a criptografia com base em chave simétrica tradicional, como a utilizada no triplo DES.

Dados confidenciais por usuário

Dados confidenciais, como credenciais de logon, e dados no nível do aplicativo, como números de cartão de crédito, números de contas bancárias, etc., precisam ser protegidos. A privacidade por meio da criptografia e a integridade através de códigos de autenticação de mensagens (MAC) são os elementos principais.

As práticas a seguir aumentam a segurança de dados confidenciais por usuário em aplicativos da Web:

• Recuperar dados confidenciais sob demanda.
• Criptografar os dados ou proteger o canal de comunicação.
• Não armazenar dados confidenciais em cookies persistentes.
• Não transmitir dados confidenciais utilizando o protocolo HTTP–GET.

Recuperar dados confidenciais sob demanda

A melhor abordagem é recuperar dados confidenciais sob demanda quando eles forem necessários em vez de mantê–los ou armazená–los em cache na memória. Por exemplo: recupere o segredo criptografado quando ele for necessário, descriptografe–o e limpe a memória (variável) uutilize para manter o segredo em texto sem formatação. Se a questão for o desempenho, considere estas opções:

• Armazenar em cache o segredo criptografado.
• Armazenar em cache o segredo em texto sem formatação.

Armazenar em cache o segredo criptografado

Recupere o segredo quando o aplicativo for carregado e o armazene em cache na memória, descriptografando–o quando o aplicativo usá–lo. Apague a cópia em texto sem formatação quando ela não for mais necessária. Essa abordagem evita o acesso ao armazenamento de dados a cada solicitação.

Armazenar em cache o segredo em texto sem formatação

Evite a sobrecarga de descriptografar o segredo várias vezes e armazenar a cópia em texto sem formatação do segredo na memória. Essa é a abordagem menos segura, mas oferece o melhor desempenho. Teste as outras abordagens antes de achar que o ganho em desempenho compensa o risco de segurança maior.
Criptografar os dados ou proteger o canal de comunicação

Se você estiver enviando ao cliente dados confidenciais pela rede, criptografe–os ou proteja o canal. Uma prática comum é utilizar SSL entre o cliente e o servidor Web. Entre servidores, a abordagem cada vez mais comum é utilizar IPSec. Para proteger dados confidenciais que trafegam entre vários intermediários, por exemplo, mensagens SOAP (Simple Object Access Protocol) do Web Service, usam criptografia no nível da mensagem.

Não armazenar dados confidenciais em cookies persistentes

Evite armazenar dados confidenciais em cookies persistentes. Se você armazenar dados em texto sem formatação, o usuário final poderá ver e modificar os dados. Se você criptografar os dados, o gerenciamento de chaves pode ser um problema. Por exemplo, a chave utilizada para criptografar os dados no cookie expirou e foi reciclada, a nova chave não consegue descriptografar o cookie persistente transmitido pelo navegador a partir do cliente.
Não transmitir dados confidenciais utilizando o protocolo HTTP–GET
Você pode evitar armazenar dados confidenciais utilizando o protocolo HTTP–GET porque ele usa seqüências de caracteres de consulta para transmitir dados. Não é possível proteger dados confidenciais utilizando seqüências de caracteres de consulta e estas são freqüentemente registradas pelo servidor

Gerenciamento de sessão

Os aplicativos da Web baseiam–se no protocolo HTTP independente, portanto, o gerenciamento da sessão é responsabilidade do aplicativo. A segurança da sessão é fundamental para a segurança geral do aplicativo.
As práticas a seguir aumentam a segurança do gerenciamento da sessão do aplicativo da Web:

• Utilizar SSL para proteger os cookies de autenticação da sessão.
• Criptografar o conteúdo dos cookies de autenticação.
• Limitar a duração da sessão.
• Proteger o estado da sessão contra acesso não autorizado.

Utilizar SSL para proteger os cookies de autenticação da sessão

Não transmita cookies de autenticação por conexões HTTP. Defina o cookie seguro corretamente nos cookies de autenticação, que instruem os navegadores a retornar os cookies ao servidor somente por conexões HTTPS.
Criptografar o conteúdo dos cookies de autenticação
Criptografe o conteúdo do cookie mesmo que você esteja utilizando SSL. Isso evita que um invasor visualize ou modifique o cookie se ele conseguir roubá–lo por meio de um ataque de scripts através de sites. Nesse caso, o invasor ainda poderia utilizar o cookie para acessar o aplicativo, mas somente enquanto ele fosse válido.

Limitar a duração da sessão

Reduza o tempo de duração das sessões para reduzir o risco de seqüestro de sessão e ataques de repetição. Quanto menor a sessão, menos tempo o invasor terá para capturar um cookie da sessão usá–lo para acessar o aplicativo.
Proteger o estado da sessão contra acesso não autorizado

Considere como o estado da sessão será armazenado. Para um melhor desempenho, você pode armazená–lo no espaço de endereço do processo do aplicativo da Web. No entanto, essa abordagem tem escalabilidade limitada e implicações em cenários de Web farm, nos quais não há garantia de que as solicitações do mesmo usuário serão tratadas pelo mesmo servidor. Nesse caso, é necessário um estado fora do processo em um servidor de estado dedicado ou um armazenamento de estado persistente em um banco de dados compartilhado. O ASP.NET suporte as três opções.
Você deve proteger o link de rede entre o aplicativo da Web e o armazenamento de estado utilizando IPSec ou SSL para reduzir o risco de espionagem. Considere também como o aplicativo da Web será autenticado pelo armazenamento de estado. Utilize a autenticação do Windows sempre que possível para evitar transmitir credenciais de autenticação em texto sem formatação pela rede e para aproveitar as diretivas de contas seguras do Windows.

Criptografia

A criptografia em sua forma básica oferece o seguinte:

• Privacidade (Confidencialidade). Esse serviço mantém um segredo como confidencial.
• Não-repúdio (Autenticidade). Esse serviço garante que um usuário não pode negar o envio de uma mensagem em particular.
• À prova de violação (Integridade). Esse serviço evita que os dados sejam alterados.
• Autenticação. Esse serviço confirma a identidade do remetente de uma mensagem.

Os aplicativos da Web freqüentemente usam criptografia para protege dados em armazenamentos persistentes ou enquanto são transmitidos pelas redes. As práticas a seguir aumentam a segurança do aplicativo da Web quando você utilizar criptografia:

• Não desenvolver sua própria criptografia.
• Manter dados descriptografados próximos do algoritmo.
• Utilizar o algoritmo e o tamanho de chave corretos.
• Proteger as chaves de criptografia.

Não desenvolver sua própria criptografia

Algoritmos e rotinas de criptografia são notoriamente difíceis de desenvolver com sucesso. Como resultado, você deve utilizar os serviços de criptografia testados fornecidos pela plataforma. Isso inclui o .NET Framework e o sistema operacional subjacente. Não desenvolva implementações personalizadas porque, geralmente, resultam em uma proteção fraca.

Manter dados descriptografados próximos do algoritmo

Ao transmitir texto sem formatação a um algoritmo, não obtenha os dados até que você esteja pronto para usá–los e armazená–los no menor número de variáveis possível.

Utilizar o algoritmo e o tamanho de chave corretos

É importante garantir que você escolheu o algoritmo certo para o trabalho certo e que você está utilizando um tamanho de chave que fornece um grau suficiente de segurança. Chaves maiores geralmente aumentar a segurança. A lista a seguir resume os principais algoritmos com o tamanho de chave que cada um usa:

• Chave DES (Data Encryption Standard) de 64 bits (8 bytes)
• Chave triplo DES de 128 bits ou chave de 192 bits (16 ou 24 bytes)
• Chaves Rijndael de 128 – 256 bits (16 – 32 bytes)
• Chaves RSA de 384 – 16.384 bits (48 – 2.048 bytes)

Para criptografar dados maiores, utilize o algoritmo de criptografia simétrica Triplo DES. Para criptografia mais lenta e mais rígida de grandes quantidades de dados, use Rijndael. Para criptografar os dados que serão armazenados por curtos períodos, você pode considerar o uso de um algoritmo mais rápido, mas mais fraco, como o DES. Para assinaturas digitais, utilize RSA (Rivest, Shamir e Adleman) ou DAS (Digital Signature Algorithm). Para hash, utilize o SHA (Secure Hash Algorithm)1.0. Para hashes com chaves, utilize o HMAC (Hash–based Message Authentication Code) SHA1.0.

Proteger as chaves de criptografia

A chave de criptografia é um número secreto utilizado como entrada para processos de criptografia e descriptografia. Para que os dados criptografados continuem seguros, a chave deve ser protegida. Se um invasor comprometer a chave de descriptografia, os dados criptografados não estarão mais seguros.
As práticas a seguir ajudam a proteger as chaves de criptografia:

• Utilizar a DPAPI para evitar o gerenciamento de chaves.
• Mudar as chaves periodicamente.

Utilizar a DPAPI para evitar o gerenciamento de chaves

Como já foi citado, uma das maiores vantagens do uso da DPAPI é que a questão do gerenciamento de chaves fica a cargo do sistema operacional. A chave utilizada pela DPAPI é derivada da senha associada à conta de processo que aciona as funções da DPAPI. Use a DPAPI para deixar o trabalho de gerenciamento de chaves para o sistema operacional.

Mudar as chaves periodicamente

Geralmente, a probabilidade de um segredo estático ser descoberto com o tempo é maior. As questões que você não pode esquecer incluem: Você o anotou em algum lugar? Bob, o administrador que detém os segredos, mudou de cargo ou saiu da empresa? Não use demais as chaves.

Manipulação de parâmetros

Com ataques de manipulação de parâmetros, o invasor modifica os dados transmitidos entre o cliente e o aplicativo da Web. Podem ser dados enviados por meio de seqüências de caracteres de consulta, campos de formulário, cookies ou em cabeçalhos HTTP. As práticas a seguir ajudam a proteger a manipulação de parâmetros do aplicativo da Web:

• Criptografar o estado de cookies confidenciais.
• Certificar–se de que os usuários não ignoram as verificações.
• Validar todos os valores enviados a partir do cliente.
• Não confiar nas informações do cabeçalho HTTP.

Criptografar o estado de cookies confidenciais

Os cookies podem conter dados confidenciais, como identificadores de sessão, ou dados utilizados no processo de autorização do lado do servidor. Para proteger esse tipo de dados contra manipulação não–autorizada, criptografe o conteúdo do cookie.

Certificar–se de que os usuários não ignoram as verificações

Certifique–se de que os usuários não ignoram as verificações manipulando parâmetros. Os parâmetros de URL podem ser manipulados pelos usuários finais através da caixa de texto de endereço do navegador. Por exemplo: o URL [url=”http://www.//IDsessão=10″%5Dhttp://www.//IDsessão=10%5B/url%5D possui um valor de 10 que pode ser alterado para algum número aleatório para receber uma saída diferente. Certifique–se de verificar isso no código do lado do servidor, não no JavaScript no lado do cliente, que pode ser desativado no navegador.

Validar todos os valores enviados a partir do cliente

Restrinja os campos que o usuário pode inserir e modificar e valide todos os valores provenientes do cliente. Se você predefiniu valores em campos de formulário, os usuários podem alterá–los e retorná–los para receber resultados diferentes. Permita somente valores bem conhecidos sempre que possível. Por exemplo, se o campo de entrada for um estado, somente entradas que correspondam ao código postal do estado devem ser permitidas.

Não confiar nas informações do cabeçalho HTTP

Os cabeçalhos HTTP são enviados no início das solicitações e das respostas HTTP. O aplicativo da Web deve certificar–se de que ele não baseia nenhuma decisão de segurança nas informações contidas nos cabeçalhos HTTP porque é fácil para um invasor manipular o cabeçalho. Por exemplo, o campo referencial do cabeçalho contém o URL da página da Web de onde ele provém. Não tome decisões de segurança com base no valor do campo referencial, por exemplo, verificar se a solicitação teve origem em uma página gerada pelo aplicativo da Web, pois o campo pode ser facilmente falsificado.

Gerenciamento de exceções

O tratamento seguro de exceções pode ajudar a evitar certos ataques de negação de serviço no nível do aplicativo e também pode ser utilizado para impedir que informações importantes no nível do sistema úteis aos invasores sejam retornadas ao cliente. Por exemplo, sem o tratamento correto de exceções, informações como detalhes do esquema do banco de dados, versões do sistema operacional, rastreamentos de pilha, nomes e caminho de arquivos, seqüências de caracteres de consulta do SQL e outras informações de valor para o invasor podem ser retornadas ao cliente.
Uma boa abordagem é projetar um gerenciamento de exceções centralizado e uma solução de registro em log e considerar a inclusão de ganchos no sistema de gerenciamento de exceções para oferecer suporte à instrumentação e ao monitoramento centralizado para ajudar os administradores de sistema.

As práticas a seguir ajudam a proteger o gerenciamento de exceções do aplicativo da Web:

• Não deixar vazar informações para o cliente.
• Registrar em log mensagens de erro com detalhes.
• Identificar as exceções.

Não deixar vazar informações para o cliente

No caso de falha, não exponha informações que poderiam resultar na divulgação de informações. Por exemplo, não exponha detalhes do rastreamento de pilha que incluam nomes de função e números de linha no caso de compilações para depuração (que não devem ser utilizadas em servidores de produção). Em vez disso, retorne mensagens de erro genéricas ao cliente.

Registrar em log mensagens de erro com detalhes
Envie mensagens de erro detalhadas ao log de erros. Envie o mínimo de informações ao usuário do serviço ou do aplicativo, como uma mensagem de erro genérica e uma identificação personalizada do log de erro que possa ser então mapeada até a mensagem detalhada nos logs de eventos. Certifique–se de não registrar no log senhas nem outros dados confidenciais.

Identificar as exceções

Utilize um tratamento de exceções estruturado e identifique condições de exceção. Isso evita que o aplicativo fique com um estado inconsistente que pode resulta na divulgação de informações. Isso também pode ajudar a proteger o aplicativo contra ataques de negação de serviço. Decida como propagar as exceções internamente no aplicativo e dê atenção especial a o que ocorre no limite do aplicativo.

Auditoria e log

Você deve executar atividades de auditoria e log nas camadas do aplicativo. Utilizando logs, é possível detectar atividades suspeitas. Elas freqüentemente indicam com antecedência um ataque devastador e os logs ajudam a resolver o risco de recusa quando os usuários recusam suas ações. Os arquivos de log podem ser exigidos em processos judiciais para provarem a transgressão dos acusados. Geralmente, o processo de auditoria é considerado mais autorizado se as auditorias forem geradas no momento exato em que um recurso é acessado e pelas mesmas rotinas que acessam o recurso.

As práticas a seguir aumentam a segurança do aplicativo da Web:

• Auditar e registrar em log o acesso entre as camadas do aplicativo.
• Considerar o fluxo de identificação.
• Registrar em log eventos importantes.
• Proteger arquivos de log.
• Fazer backup dos arquivos de log e os analisar regularmente.

Auditar e registrar em log o acesso entre as camadas do aplicativo

Audite e registre em log o acesso entre as camadas do aplicativo no caso de não–repúdio. Use uma combinação de log no nível do aplicativo e recursos de auditoria da plataforma, como a auditoria do Windows, do IIS e do SQL Server.

Considerar o fluxo de identificação

Considere como o aplicativo transmitirá a identificação do chamador entre as várias camadas do aplicativo. Você tem duas opções básicas. Você pode transmitir a identificação do chamador no nível do sistema operacional utilizando a delegação do protocolo Kerberos. Isso permite o uso da auditoria no nível do sistema operacional. A desvantagem dessa abordagem é que ela afeta a escalabilidade, pois significa que não pode haver nenhum pool de conexão do banco de dados ativo na camada intermediária. Como alternativa, você pode transmitir a identificação do chamador no nível do aplicativo e utilizar identificações confiáveis para acessar recursos de back–end. Com essa abordagem, você tem que confiar na camada intermediária e existe um risco de recuso. Você deve gerar faixas de auditoria na camada intermediária que possam ser correlacionadas às faixas de auditoria de back–end. Para isso, você deve certificar–se de que os relógios dos servidores estão sincronizados, embora o Microsoft Windows 2000 e o Active Directory façam isso por você.

Registrar em log eventos importantes

Os tipos de eventos que devem ser registrados incluem tentativas de logon bem–sucedidas ou não, modificação de dados, recuperação de dados, comunicações de rede e funções administrativas, como ativar ou desativar o registro em log. Os logs devem inclui a hora do evento, a localização do evento incluindo o nome da máquina, a identificação do usuário atual, a identificação do processo que iniciou o evento e uma descrição detalhada do evento.

Proteger arquivos de log

Proteja os arquivos de log utilizando as listas de controle de acesso do Windows e restrinja o acesso a eles. Isso dificulta para os invasores a alteração dos arquivos de log para encobrir seus rastros. Reduza o número de pessoas que podem manipular os arquivos de log. Autorize acesso somente a contas altamente confiáveis, como as dos administradores.

Fazer backup dos arquivos de log e os analisar regularmente

Não há porquê criar um log se os arquivos de log nunca são analisados. Os arquivos de log devem ser removidos dos servidores de produção regularmente. A freqüência de remoção depende do nível de atividade do aplicativo. O projeto deve considerar o modo como os arquivos de log serão recuperados e movidos para servidores offline para análise. Quaisquer protocolos e portas adicionais abertos no servidor Web com essa finalidade devem ser fechados de forma segura.

Diretrizes de projeto do aplicativo

Categoria Diretrizes

Validação da entrada Não confiar na entrada; considerar a validação da entrada centralizada.

Não confiar na validação do lado do cliente. Ter cuidado com questões de canonização. Restringir, rejeitar e limpar a entrada. Validar dados por tipo, tamanho, formato e intervalo.

Autenticação Dividir o site nas áreas de acesso anônimo, identificado e autenticado. Utilizar senhas de alta segurança. Oferecer suporte para senhas com validade e desativação de conta. Não armazenar credenciais (utilizar hashes unidirecionais com valores falsos). Criptografar os canais de comunicação para proteger os identificadores de autenticação.
Transmitir cookies de autenticação de formulários somente por conexões HTTPS.

Autorização Utilizar contas com a menor quantidade de privilégios. Considerar a granulação da autorização.

Aplicar a separação de privilégios. Restringir o acesso do usuário a recursos no nível do sistema.

Gerenciamento de configuração Utilizar contas com processos e serviços com a menor quantidade de privilégios. Não armazenar credenciais em texto sem formatação. Utilizar autenticação e autorização rígidas nas interfaces administrativas.

Não utilizar a LSA. Proteger o canal de comunicação para administração remota. Evitar armazenar dados confidenciais no espaço da Web.

Dados confidenciais Evitar armazenar segredos. Criptografar dados confidencias transmitidos. Proteger o canal de comunicação. Fornecer controles de acesso rígidos aos armazenamentos de dados confidenciais. Não armazenar dados confidenciais em cookies persistentes. Não transmitir dados confidenciais utilizando o protocolo HTTP–GET.

Gerenciamento de sessão Limitar a duração da sessão. Proteger o canal. Criptografar o conteúdo dos cookies de autenticação. Proteger o estado da sessão contra acesso não autorizado.

Criptografia Não desenvolver sua própria criptografia. Utilizar recursos da plataforma testados. Manter dados descriptografados próximos do algoritmo. Utilizar o algoritmo e o tamanho de chave corretos. Evitar o gerenciamento de chaves (utilizar DPAPI). Mudar as chaves periodicamente. Armazenar chaves em um local restrito.

Manipulação de parâmetros Criptografar o estado de cookies confidenciais. Não confiar nos campos que o cliente pode manipular (seqüências de caracteres de consulta, campos de formulário, cookies ou cabeçalhos HTTP). Validar todos os
valores enviados a partir do cliente.

Gerenciamento de exceções Utilizar um tratamento de exceções estruturado. Não revelar detalhes confidenciais da implementação do aplicativo. Não registrar em log dados particulares, como senhas. Considerar uma estrutura de gerenciamento de exceções centralizado.

Auditoria e log Identificar comportamento mal–intencionado. Saber como é um tráfego normal. Executar atividades de auditoria e log em todas as camadas do aplicativo. Proteger o acesso aos arquivos de log. Fazer backup dos arquivos de log e os analisar regularmente.

A segurança deve difundir–se por todos os estágios do ciclo de desenvolvimento do produto e deve ser um dos pontos principais do projeto do aplicativo. Preste atenção, especialmente, ao projeto de uma estratégia rígida de autenticação e autorização. Lembre–se também de que a maioria dos ataques no nível do aplicativo utiliza dados com entrada mal–intencionada e uma validação fraca da entrada do aplicativo. As instruções apresentadas neste módulo ajudarão você com esses e outros aspectos complicados referentes ao projeto e à criação de aplicativos seguros.

fonte:msdn,MXStudio

jDigiClock – Digital Clock (HTC Hero inspired).

Publicado em 16/03/201016/09/2015 por homdigitalis

jDigiClock

Digital Clock (HTC Hero inspired)

Author: Radoslav Dimov
Version: 2.1 (Changelog)
Download: jdigiclock.zip
Licence: Dual licensed under the MIT and GPL licenses.

Introduction

jDigiClock is a jQuery plugin inspired from HTC Hero Clock Widget.

Examples

Tue, 16 Mar

0°C

Update Weather …

Getting started

To use the jDigiClock plugin, include the jQuery library, the jDigiClock source file and jDigiClock core stylesheet file inside the <head> tag of your HTML document:

<link rel="stylesheet" type="text/css" href="css/jquery.jdigiclock.css" />
http://lib/jquery-1.3.2.min.js
http://lib/jquery.jdigiclock.js

To setup jDigiClock, add the following code inside the <head> tag of your HTML document:

    $(document).ready(function() {
        $('#digiclock').jdigiclock({
            // Configuration goes here
        });
    });

jDigiClock accepts a lot of configuration options, see chapter “Configuration” for further informations.

jDigiClock expects a very basic HTML markup structure inside your HTML document:

Configuration

jDigiClock accepts a list of options to control the appearance and behaviour of the Digital Clock. Here is the list of options you may set:

Property
Type
Default
Description

clockImagesPath
string
“images/clock/”
Clock images path.

weatherImagesPath
string
“images/weather/”
Weather images path.

am_pm
boolean
false
Specifies the AM/PM option.

weatherLocationCode
string
“EUR|BG|BU002|BOURGAS”
Weather location code (see: WeatherLocationDatabase.txt).

weatherMetric
string
“C”
Specifies the weather metric mode: C or F.

weatherUpdate
integer
0
Weather update in minutes.

proxyType
string
“php”
Specifies proxy type: php or asp (see: README.txt).

Compatibility

jDigiClock has been tested and works on the following browsers:

Internet Explorer 7 (PC)
FireFox 3.5 (PC/Linux)
Google Chrome 3.0 (PC)
Safari 4.0 (PC)

50 Fresh JavaScript Tools That Will Improve Your Workflow – Smashing Magazine

Publicado em 16/03/201017/09/2015 por homdigitalis

JavaScript is an integral part of the RIA revolution. JavaScript allows developers to create rich and interactive web interfaces and establish asynchronous communication with servers for constantly up-to-date data without a page refresh.

Many things that were once accomplished using Flash objects can now be built using JavaScript – with the added benefit that it is free, typically more web and mobile accessible under most circumstances using best practices for development techniques, and without the need to use proprietary software for development.

Though JavaScript has been around for a while, new tools, techniques, and information are constantly being pumped out to continually push the technology into greater heights. In this article, we wish to share with you a huge list of fresh and new tools and resources that JavaScript developers will find useful and informative.

Here are a few other posts that you might find interesting:

[By the way: The network tab (on the top of the page) is updated several times a day. It features manually selected articles from the best web design blogs!]

Useful JavaScript Tools

FireUnit
Unit testing is an integral part of building high-performance and efficient web applications. John Resig (creator of jQuery library) and Jan Odvarko have developed an excellent Firefox/Firebug extension called FireUnit which gives developers logging and testing capabilities via a simple JavaScript API. For those interested in the tool, you should also read Odvarko’s post detailing the usage of FireUnit.

Sugar Test
SugarTest makes it easy to write elegant and understandable JavaScript tests. Its API is inspired by both RSpec, Shoulda and jQuery. It works as a DSL running on top of JsUnitTest.

JS.Class: Ruby-style JavaScript
JS.Class is a library designed to facilitate object-oriented development in JavaScript. It implements Ruby’s core object, module and class system and some of its metaprogramming facilities, giving you a powerful base to build well-structured OO programs.

JSON Formatter and Validator
The JSON Formatter was created to help with debugging. As data expressed as JSON is often written without line breaks to save space, it became extremely difficult to actually read it. This tool hopes to solve the problem by formatting the JSON into data that is easily readable by human beings.

Faux Console: Simulating a Firebug, Safari or Opera debugging in IE
Browsers like Safari, Opera and Firefox use the Firebug extension that offers a developer a comfortable way to output debugging information using the console.log() command. Microsoft Internet Explorer does not support this though – Faux Console is a small JavaScript that you can embed in the document to have a basic debugging console in IE.

JS Bin
JS Bin is a web application for testing and debugging JavaScript and CSS collaboratively. You input your source code and save it to a publicly-accessible URL which you can then share to your fellow developers or in social networking outlets like Twitter or Facebook groups. Be sure to check out the video introduction to see JS Bin in action.

PHP.JS
PHP.JS is an open source project in which we try to port PHP functions to JavaScript. By including the PHP.JS library in your own projects, you can use your favorite PHP functions client-side.

Page Speed
Page Speed, released by Google, is a Firefox/Firebug extension very similar to YSlow that evaluates your web pages for performance. Read more about Page Speed best practices to see what aspects of a web page are being evaluated. YSlow and Page Speed are based off Steve Souder’s work (who worked for Yahoo! and now works for Google).

prettyPrint
prettyPrint is an in-browser JavaScript utility for dumping variable information, inspired by ColdFusion’s built-in cfdump utility function. Using prettyPrint on JS objects, variables, and arrays will give you a large array of information about them, which you can then use for debugging purposes or simply for gathering data about them for documentation.

Spket IDE
Spket is an excellent toolkit for JavaScript and XML development. It has a robust and intuitive GUI, and integrates with popular and powerful JavaScript/Ajax libraries such as Y!UI and jQuery. Its JavaScript Formatter feature gives you unparalleled control and standardization for you or your team’s JavaScript code formatting standards.

Obtrusive JavaScript Checker
Obtrusive JavaScript Checker, created by Robert Nyman, is a tool for finding inline JavaScript on web pages. It highlights elements that have inline JavaScript properties and provides a summary report when you mouse over them. The tool is available as a Firefox extension or a Greasemonkey script.

Highlight.js
Highlight.js highlights syntax in code examples on blogs, forums and other web pages. The tool works automatically: it finds blocks of code, detects a language and highlights it accordingly.

Javascript Compressor
Javascript Compressor is a web-based tool for compressing your JavaScript to reduce their file sizes. It works by removing unnecessary characters (such as extra tabs and spaces). Developers who use the tool to compress their code can also use the decoding feature to uncompress their source code. It also obfuscates your code, making it harder to read – which can be desirable if you want to delay prying eyes from analyzing your publicly-available code base.

Firediff
Firediff is a Firefox/Firebug extension that allows you to track changes in the DOM and CSS. By logging these changes, you can gain information about how web applications work, and what elements (and what properties) are being altered by way of DOM manipulation.

RockStar Web Profiler
RockStar Web Profiler (aka Razor) logs and profiles information about client-side performance. It provides developers with a console for analyzing the data gathered by the tool. Check out the RockStar Web Profiler presentation to get an overview of its many awesome features.

bookmarklet maker
This plain and simple web tool allows you to create JavaScript-based bookmarklets. Usage is simple: simply copy and paste your source code into it and it will output the processed code in the lower pane.

Tiny JS
Tiny JS is an online directory of small but powerful plugins for popular JavaScript/Ajax libraries (MooTools, jQuery, and YUI at the moment). Its aim is to hunt down and feature lightweight plugins that give you a lot of bang for the buck.

JSCharts
JS Charts is a free JavaScript based chart generator that requires little or no coding. With JS Charts drawing charts is a simple and easy task, since you only have to use client-side scripting (i.e. performed by your web browser). No additional plugins or server modules are required. It’s enough to include the scripts, prepare your chart data in XML or JavaScript Array and your chart is ready.

Glimmer
Glimmer is an interactive design tool for incorporating slick JavaScript-based animation effects using the jQuery library. Glimmer comes with a wizard-style user interface which can reduce the amount of coding that you have to write manually.

JSSPec
A testing environment for JavaScript that runs on IE 6+, Firefox 2+ and Safari 3+. The tool shows differences between expected value and actual value, displays the failed line exactly and supports conditional execution. Released under GNU and available for free download.

CodeRun Code Search
CodeRun’s Code Search tool lets you search and view user-submitted Ajax, PHP, and .NET source code. Once you’ve found a script or project that you’re interested in, you can edit it via their web-based IDE without having to download the project locally.

BaseJS: A Mobile (Safari) Javascript Framework
a simple, lightweight framework created specifically for Mobile Safari (perfect for iPhone development).

MochaUI
MochaUI is a web-based tool for building web application interfaces built on top of the MooTools JavaScript framework. Jump right in by taking MochaUI for a spin in their demo page.

Utility Libraries and Components for JavaScript

narwhal
narwhal is a server-side JavaScript library following the ServerJS standard. Developers can create and share “packages” for website widgets, site features, programming patterns, in a similar fashion as PEAR for PHP.

uploadify
uploadify is a useful jQuery plugin for dealing with file uploads. It’s powered by a simple PHP script for handling the server-side stuff. Be sure to check out the uploadify demos to see the plugin in action.

Blackbird
Blackbird lets you log messages in JavaScript using a simple and intuitive JS-based API. The library also provides you with an attractive console GUI for viewing and analyzing messages. No more annoying alert() functions to see your objects’ contents (which can be frustrating for printing out array values) and for setting breakpoints.

Booklaylet
Booklaylet is a JS library for letting you easily deploy your bookmarklet applications. The implementation is dead simple: take the Booklaylet source and modify it to point to your app’s URL.

JavaScripTools
JavaScipTools is a collection of useful JS components, functions, and classes with the aim of addressing some of the more common web developer tasks such as parsing and formatting of data types (i.e. date and time). It also comes with a dynamic table function for creating sortable HTML tables.

Doodle.js
HTML 5’s Canvas element gives developers a way to draw stuff on web pages programmatically. Doodle.js is a utility library/framework for working with more complex and robust Canvas drawing processes. Check out Spiral Pattern demo and the Marbles in Space (3D simulation) demo in a browser that already supports Canvas to get a feel for how Doodle.js works.

liteAJaX
liteAJaX is a lightweight JavaScript class for working with AJAX. This library is perfect for projects that don’t use a JavaScript/Ajax framework or projects that don’t need a more robust and fully-featured framework.

Burst
Burst is a vector animation engine for HTML 5’s Canvas element. With it, you can create smooth, Flash-like animation effects for browsers that support Canvas.

JSTestDriver
JSTestDriver is a Java-based framework for creating unit test following Test-Driven Development philosophies and best practices. Be sure to check out this video demonstration of JSTestDriver in action.

jsPDF
This library allows you to create PDF’s using nothing else but JavaScript. See the jsPDF demo page to see the library in action.

Useful JavaScript Libraries

GlassBox
GlassBox is a beautiful and refreshing take on modal windows that creates an interesting feeling of transparency as if you were looking through a glass. Check out the example page to see different types of GlassBox implementations.

jQuery TOOLS
jQuery TOOLS is a toolbox that gives developers some of the most popular UI design patterns at their disposal in an easy-to-use manner. View some of the things you can do with jQuery TOOLS in the project’s demo page.

Moousture
Moosture is a JavaScript library for dealing with mouse gestures, written on top of the MooTools framework.

Tablecloth
Tablecloth is a lightweight and unobtrusive JavaScript library for styling and adding dynamic user interaction to HTML tables.

Unobtrusive Table Actions Script
This simple and lightweight library brings together a set of common and useful functions for dealing with HTML tables, such as zebra-striping rows, highlighting rows on mouse over, and column highlighting.

LivePipe
LivePipe is a set of widgets and controls for adding common user interaction components to web applications using the Prototype JavaScript framework.

JavaScript Graphical / Virtual Keyboard Interface
This JavaScript package adds a virtual keyboard interface into web pages.

Tipmage
Tipmage is a JavaScript class for handling tooltips and annotations on images, similar to annotated images on Flickr.

qGallery
qGallery is a simple but beautiful JavaScript for creating image galleries with smooth and slick animation effects.

Educational JavaScript Resources and Tutorials

Ajax Frameworks Decision Center
For large companies, committing to a JavaScript/Ajax framework such as Prototype, MooTools, or jQuery is a big decision because it affects a large amount of employees and will dictate the direction of the company’s client-side interaction and RIA development philosophies. Using the Ajax Frameworks Decision Center gives you an organized, quantitative, and thorough method for making a solid decision.

jQuery vs MooTools
This single-page site by MooTools Dev Team member Aaron Newton is a comparative look into jQuery versus MooTools.

Ajax Framework Analysis Results
This analysis of popular JavaScript/Ajax frameworks (Dojo, Ext JS, GWT, YUI) is a great resource for gathering research data for your own frameworks: the analysis matrix factors in criteria such as scalability, extensibility, quality and quantity of documentation, and much more. You can adapt this matrix, tweak their weights, and modify criterions to help you decide which JS framework to go with.

Sexy Drop Down Menu w/ jQuery & CSS
In this tutorial, you’ll learn how to create a multi-tiered drop down menu with the use of the jQuery library.

Easy Display Switch with CSS and jQuery
This tutorial outlines a method for using jQuery to smoothly-transition into different viewing modes, which can be helpful in image galleries.

Create a Slick and Accessible Slideshow Using jQuery
This is a step-by-step jQuery tutorial that I wrote for creating a simple and slick slideshow that can be adapted to display different content types. Check out the demo page to see the slideshow in action.

Learning Advanced JavaScript
John Resig has a slideshow-style, web-based tutorial on advanced JavaScript development. It is a wonderful stepping-stone for JavaScript developers ready to make the leap into RIA development using JavaScript.

JavaScript tests & Compatibility tables
This resource is a well-organized cheatsheet for JavaScript methods cross-browser compatibility backed by sample tests that you can run to see how they work (or don’t work) in your browser.

Code Conventions for the JavaScript
On this page, you can find suggested coding conventions for JavaScript. It is important to note that there is no one correct convention, but this is a great place to start developing your own.

Jogo em Java

Publicado em 12/03/201017/09/2015 por homdigitalis

Bom hoje nós vamos desenvolver um game educativo bem simples em Java, desenvolvi esse game para ensinar as pessoas que estão começando a mexer no computador e tem problemas com o mouse, ele consiste em vários quadradinhos na tela e a jogador tem que ir passando o mouse no quadradinho vermelho que vai mudando de lugar.

O game que vamos desenvolver tem essa aparência, são 30 quadradinhos que ao passar o mouse eles vão mudando de cor, mas eles têm que passar o mouse em uma ordem se não, não tem sentido o game né.

Pronto, vamos por a mão no código ehehehh.

Primeiro vamos criar uma classe para fazer os quadradinhos, então crie a classe Quadrado.

O quadrado tem que ter, posição X, Y, largura, altura, e uma cor.

import java.awt.Color;

public class Quadrado {
        private int x;
        private int y;
        private int width;
        private int height;
        private Color cor;

    public Quadrado(int x, int y, int width, int height) {
        this.x = x;
        this.y = y;
        this.width = width;
        this.height = height;
    }

public Quadrado(){

}

    public Color getCor() {
        return cor;
    }

    public void setCor(Color cor) {
        this.cor = cor;
    }

    public int getHeight() {
        return height;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int getWidth() {
        return width;
    }

    public void setWidth(int width) {
        this.width = width;
    }

    public int getX() {
        return x;
    }

public void setX(int x) {
this.x = x;

}

    public int getY() {
        return y;
    }

    public void setY(int y) {
        this.y = y;
    }
}

Pronto já temos os quadradinhos precisamos criar agora nossa janela, a janela é mais complicada porque temos que criar um modelo de como vai ser a tela, para depois quando formos criar a tela do game programaremos somente que vamos usar.

A Classe Janela deverá estender a JFrame, pois assim teremos uma janela, precisaremos também implementar duas interfaces a MouseListener e a MouseMotionListener para controlarmos o mouse, deixaremos essa classe abstrata.

Então ficará assim:

import java.awt.event.MouseEvent;
import java.awt.event.MouseListener;
import java.awt.event.MouseMotionListener;
import javax.swing.JFrame;

public abstract class Janela extends JFrame implements MouseListener, MouseMotionListener{
}

Você não precisa, mas é interessante implementar todos os métodos das classes MouseListener, MouseMotionListener, porque depois só sobrescrevemos só aqueles que vamos usar entendeu??? Hehehhe.

Então até agora a classe Janela está assim:

public abstract class Janela extends JFrame implements MouseListener, MouseMotionListener {

public void mouseClicked(MouseEvent e) {
}

public void mousePressed(MouseEvent e) {
}

public void mouseReleased(MouseEvent e) {
}

public void mouseEntered(MouseEvent e) {
}

public void mouseExited(MouseEvent e) {
}

public void mouseDragged(MouseEvent e) {
}

public void mouseMoved(MouseEvent e) {
}
}

Continuando a classe janela precisamos de uma variável para guardar em que fase nos estamos e precisamos também criar os quadradinhos.

    private int numeroDaFase;
    public int getNumeroDaFase() {
        return numeroDaFase;
    }

    public void setNumeroDaFase(int numeroDaFase) {
        this.numeroDaFase = numeroDaFase;
    }

protected ArrayList<Quadrado> quad = new ArrayList<Quadrado>();

    public ArrayList<Quadrado> getQuad() {
        return quad;
    }

    public void setQuad(ArrayList<Quadrado> quad) {
        this.quad = quad;
     }

Vamos criar inicializar os componentes e fazer um teste?

Para isso precisamos criar mais outro método e depois uma classe, o método é o inicializarComponetes(), assim inicializamos tudo em um único método assim fica mais fácil depois.

public void inicializaComponetes() {
    addMouseListener(this);
    addMouseMotionListener(this);
     setResizable(false);
     setSize(740, 640);
     setTitle(”:: Elzo Brito – Game ::”);
     setDefaultCloseOperation(EXIT_ON_CLOSE);
    show();
}

Agora vamos criar a classe MinhaTela com ela vamos criar a tela, no primeiro momento só para testar a classe Janela depois vamos usar ela para ser nossa tela.

public class MinhaTela extends Janela{

public MinhaTela(){

inicializaComponetes();

}

Pronto agora na classe Main crie uma instancia de MinhaTela e veja o que fizemos até agora…

public class Main {

public static void main(String[] args) {

MinhaTela mt = new MinhaTela();

}

Pode não parecer, mas 50% do nosso game já está pronto J, vamos dar continuidade e desenhar na tela os quadrados que compõe a tela, para isso vamos criar outra classe para facilitar nosso trabalho, criaremos então a classe Fase é nela que estarão os elementos que vamos usar no jogo.

A classe Fase tem um array com 30 quadrados que formarão a tela, alem dos dos métodos setQ() que servirá para setar a posição dos quadrados na classe e getQ() para recuperar os quadrados depois, o construtor da classe cria os 30 quadradinhos já passando a posição que cada um vai estar na tela.

public class Fase {

private Quadrado[] q = new Quadrado[30];

public Quadrado[] getQ() {

return q;

}

public void setQ(Quadrado[] q) {

this.q = q;

}

public Fase() {

Quadrado[] q = new Quadrado[30];

q[0] = new Quadrado(20, 40, 100, 100);

q[1] = new Quadrado(140, 40, 100, 100);

q[2] = new Quadrado(260, 40, 100, 100);

q[3] = new Quadrado(380, 40, 100, 100);

q[4] = new Quadrado(500, 40, 100, 100);

q[5] = new Quadrado(620, 40, 100, 100);

q[6] = new Quadrado(20, 160, 100, 100);

q[7] = new Quadrado(140, 160, 100, 100);

q[8] = new Quadrado(260, 160, 100, 100);

q[9] = new Quadrado(380, 160, 100, 100);

q[10] = new Quadrado(500, 160, 100, 100);

q[11] = new Quadrado(620, 160, 100, 100);

q[12] = new Quadrado(20, 280, 100, 100);

q[13] = new Quadrado(140, 280, 100, 100);

q[14] = new Quadrado(260, 280, 100, 100);

q[15] = new Quadrado(380, 280, 100, 100);

q[16] = new Quadrado(500, 280, 100, 100);

q[17] = new Quadrado(620, 280, 100, 100);

q[18] = new Quadrado(20, 400, 100, 100);

q[19] = new Quadrado(140, 400, 100, 100);

q[20] = new Quadrado(260, 400, 100, 100);

q[21] = new Quadrado(380, 400, 100, 100);

q[22] = new Quadrado(500, 400, 100, 100);

q[23] = new Quadrado(620, 400, 100, 100);

q[24] = new Quadrado(20, 520, 100, 100);

q[25] = new Quadrado(140, 520, 100, 100);

q[26] = new Quadrado(260, 520, 100, 100);

q[27] = new Quadrado(380, 520, 100, 100);

q[28] = new Quadrado(500, 520, 100, 100);

q[29] = new Quadrado(620, 520, 100, 100);

setQ(q);

}

Agora vamos terminar a classe Janela(), nela vamos criar mais um método e sobrescrever outro, o método que vamos criar é o MyTela(), ele servirá para setar a posição dos quadradinhos na classe janela().

public void myTela(){

Fase f = new Fase();

Quadrado[] q = new Quadrado[30];

q = f.getQ();

for(int i=0;i<30;i++){

q[i].setCor(Color.BLACK);

quad.add(q[i]);

}

q[0].setCor(Color.red);

}

Pronto ele cria uma instancia de fase e adiciona no nosso ArrayList a posição de todos os quadradinhos, agora precisamos sobrescrever o método Paint(Graphics g) ele é responsável por desenhar a tela e como queremos desenhar os quadradinhos na tela então precisamos dar uma arrumada nele.

@Override

public void paint(Graphics g) {

g.setColor(Color.WHITE);

g.fillRect(0, 0, 20, 650);

g.fillRect(120, 0, 20, 650);

g.fillRect(240, 0, 20, 650);

g.fillRect(360, 0, 20, 650);

g.fillRect(480, 0, 20, 650);

g.fillRect(600, 0, 20, 650);

g.fillRect(720, 0, 20, 650);

g.fillRect(0, 0, 740, 40);

g.fillRect(0, 140, 740, 20);

g.fillRect(0, 260, 740, 20);

g.fillRect(0, 380, 740, 20);

g.fillRect(0, 500, 740, 20);

g.fillRect(0, 620, 740, 20);

for(int i=0;i<30;i++){

g.setColor(quad.get(i).getCor());

g.fill3DRect(quad.get(i).getX(), quad.get(i).getY(), quad.get(i).getWidth(), quad.get(i).getHeight(), true);

}

Quase pronto vamos alterar o método inicializaComponentes() para chamar o MyTela() pois se não, não conseguiremos desenhar a tela sem a posição dos quadradinho correto???

public void inicializaComponetes() {

addMouseListener(this);

addMouseMotionListener(this);

setResizable(false);

setSize(740, 640);

setTitle(”:: Elzo Brito – Game ::”);
setDefaultCloseOperation(EXIT_ON_CLOSE);

myTela();

show();

}

Como será que a tela ficou??

Só falta agora a lógica do game, como havíamos pensando antes, o nosso game é para pessoas que não sabem mexer com o mouse então quando passar o mouse no quadradinho vermelho ele tem que mudar de lugar forçando a pessoa a seguir-lo com o mouse, vamos então para a classe MinhaTela() pois é nela que iremos por um pouco da lógica do nosso game.

public void pintarQuad(int x){

try {

if (quad.get(x – 1).getCor() == Color.ORANGE) {

quad.get(x + 1).setCor(Color.RED);

quad.get(x – 1).setCor(Color.PINK);

quad.get(x).setCor(Color.ORANGE);

}

catch(java.lang.ArrayIndexOutOfBoundsException ex){

if(quad.get(0).getCor() == Color.RED){

quad.get(1).setCor(Color.RED);

quad.get(0).setCor(Color.ORANGE);

}

catch(java.lang.IndexOutOfBoundsException ex){}

repaint();

}

Adicione esse método pintarQuad(int x), ele serve para pintar o quadrado onde passamos o mouse, se passamos o mouse no 1º quadradinho ele deve ficar amarelo e o 2º quadradinho deve ficar vermelho se passarmos o mouse no 2º quadradinho ele deve ficar amarelo o 3º quadradinho deve ficar vermelho e o 1º quadradinho fica rosinha.

Para finalizar precisamos do movimento do mouse correto? Isso então vamos criar uma classe para trabalharmos só com o movimento do mouse, vamos criar então a classe FaseMouseMove() nela trabalharemos o movimento do mouse sobre os quadradinhos, ela deve importar o MouseEvent, estender a MinhaTela() e sobrescrever o método mouseMoved(MouseEvent e).

import java.awt.event.MouseEvent;

public class FaseMouseMove extends MinhaTela{

@Override

public void mouseMoved(MouseEvent e) {

for(int i=0;i<30;i++){

if(e.getX() > quad.get(i).getX() && e.getX() < (quad.get(i).getWidth() + quad.get(i).getX()) && e.getY() > quad.get(i).getY() && e.getY() < (quad.get(i).getHeight()+quad.get(i).getY())){

pintarQuad(i);

}

Esse IF gigante testa a condição do ponteiro do mouse, se o ponteiro do mouse estiver dentro do quadradinho ele chama então o metodo pintarQua(int i) passando o número do quadradinho que o mouse estar em cima, pronto o game esta criado basta apenas criar uma instancia da classe FaseMouseMove() na classe Main() e pronto é só jogarrrr

public class Main {

public static void main(String[] args) {

FaseMouseMove fmm = new FaseMouseMove();

}

Pronto galera espero que tenham gostado do artigo, quem quiser fazer o download do projeto basta clicar no link abaixo, ele foi desenvolvido no NetBeans.

http://elzobrito.com/arquivos/desenvolvimento/gameeducativo/GameEducativo.zip

HTML 5

Publicado em 12/03/201017/09/2015 por homdigitalis

Beleza pessoal? Depois de mais de um ano sem escrever aqui no MX Studio, volto falando sobre a nova versão do HTML.

Vamos lá!

O HTML 5 veio com grandes novidades, podendo até substituir algumas funções que normalmente era utilizado no flash, como player de audio ou vídeo, por exemplo. A nova versão e muito mais robusta, antes para estruturar um documento, era usado div’s com o atributo id, para identificar cada parte do site, agora na nova versão isso foi melhorado, para cada parte da estrutura existe uma tag especifica, o que deixa o código muito mais estruturado. Abaixou vou mostrar dois exemplos, como era no HTML 4 e como é agora na nova versão. Também vou listar algumas novas tags.

Sintaxe HTML 4 x HTML 5:

HTML 4

<?xml version=”1.0″ encoding=”UTF-8″?>

<html xmlns=”http://www.w3.org/1999/xhtml”>

<head>

<title>Titulo do Documento</title>

</head>

<body>

</body>

</html>

HTML 5

<?xml version=”1.0″ encoding=”UTF-8″?>

<html xmlns=”http://www.w3.org/1999/xhtml”>

<head>

<title>Titulo do Documento</title>

</head>

<body>

<header>Topo</header>

<nav>Menu de Navegação</nav>

<article>Conteudo</article>

<footer>Rodapé</footer>

</body>

</html>

Abaixo segue as novas tags.

selection – representa um documento genérico ou seleção de tags. Pode ser usado em conjunto com os elementos h1, h2, h3, h4, h5 e h6.
article – representa um pedaço independente do conteúdo de um documento, como um blog ou artigo de jornal.
aside – representa uma parte do conteúdo que é apenas ligeiramente relacionado com o restante da página.
hgroup – representa o cabeçalho de uma seção.
footer – representa um rodapé para uma seção e pode conter informações sobre o autor, copyright,…
nav – representa uma seção do documento destinada à navegação.
figure – pode ser usado para associar uma legenda junto com algum documento incorporado, como uma imagem ou vídeo.

<figure>

<video src=”ogg”></video>

<figcaption>Example</figcaption>

</figure>

figcaption – fornece a legenda.
video e audio para conteúdos multimídia.
embed – plugins.
marker – representa uma série de texto marcado.
progress – representa uma conclusão de uma tarefa, como baixar ou executar uma série de operações.
meter – representa uma medida, como o uso do disco.
time – representa uma data e/ou tempo.
ruby rb e rp – permite a marcação de anotações de Ruby.
canvas – é utilizada para renderização de gráficos bitmap.
command – representa um comando que o usuário pode invocar.
details – representa informações adicionais ou controles que o usuário pode obter sobre uma procura. O elemento summary fornece um resumo.
datalist – em conjunto com o atributo list usado na tag input pode ser usada para fazer caixas de combinação:

<input list=”browsers”>

<datalist>

<option value=”Safari”>

<option value=”Internet Explorer”>

<option value=”Opera”>

<option value=”Firefox”>

</datalist>

Isso só foi uma amostra da nova versão, nos próximos artigos vou estar mostrando como utilizar a nova versão do HTML 5.

Até++!

Very Basic Ajax Example (obtrusive)

Publicado em 04/03/201017/09/2015 por homdigitalis

Very basic Ajax example (obtrusive)

Example

Let there be Ajax magic

Source Code

$(document).ready(function(){
  $('.ajaxtrigger').click(function(){
    $('#target').load('ajaxcontent.html');
  });
});

http://icant.co.uk/articles/things-to-know-about-ajax/very-simple-ajax.html#

Snipplely–Guarde o seu precioso código

Snipplely – Guarde o seu precioso código

Asterisk – transforme o seu PC numa central telefónica

Asterisk – Transforme um PC numa Central Telefónica

Common Security Mistakes

1. Cross-site scripting (XSS)

2. Cross-site request forgery (CSRF)

3. Click-jacking

4. SQL injection

5. Shell injection

6. Phishing

Summary

Further reading

Criar traduções para extensões Joomla

How to create translation for Joomla! extensions

Directrizes de Projecto – proteger aplicativos Web

jDigiClock – Digital Clock (HTC Hero inspired).

jDigiClock

Digital Clock (HTC Hero inspired)

Contents

Introduction

Examples

Getting started

Configuration

Compatibility

50 Fresh JavaScript Tools That Will Improve Your Workflow – Smashing Magazine

Useful JavaScript Tools

Utility Libraries and Components for JavaScript

Useful JavaScript Libraries

Educational JavaScript Resources and Tutorials

Jogo em Java

HTML 5

Very Basic Ajax Example (obtrusive)

Very basic Ajax example (obtrusive)

Example

Source Code