Portfolio Individual 4° Semestre ADS UNOPAR 2014

8/10/2019 Portfolio Individual 4 Semestre ADS UNOPAR 2014

1/10

Portfolio Individual - Curso Superior de ADS - IVSemestre

SISTEMA DE ENSINO PRESENCIAL CONECTADO

CURSO SUPERIOR DE TECNOLOGIA EM

ANLISE E DESENVOLVIMENTO DE SISTEMAS

WANDERLEY NUNES CRISTO

DESENVOLVIMENTO DE SISTEMAS DE INFORMAO II

Produo Textual InterdisciplinarPortfolio

Trabalho apresentado ao Curso Superior de Tecnologia em Anlise e Desenvolvimento de

Sistemas Universidade Norte do Paran - UNOPAR, para as disciplinas Banco de Dados II,

Anlise Orientada a Objetos II, Programao Orientada a Objetos, Programao para Web I e

Seminrios IV.

Prof.: Roberto Y. Nishimura, Anderson Emdio M.Gonalves, Marcio Roberto Chiaveli e Prof.Veronice de Freitas.

Tutor eletrnico: Jose Henrique Lopes Oliveira Bento

Tutor de sala: Rosinaldo Leo dos Santos

Breves

2014

SUMRIO

1 INTRODUO ..................................................................................................... 3

2 OBJETIVO ........................................................................................................... 4

3 SEGURANA NO DESENVOLVIMENTO DE APLICAES WEB..................... 5

3.1 VULNERABILIDADES COMUNS ..................................................................... 63.2 UTILIZAES DE FIREWALLS E PROTOCOLO HTTPS. .............................. 7

3.2.1 FIREWALLS .................................................................................................. 7

3.2.2 HTTPS: ......................................................................................................... 8

4 DIAGRAMA DE ATIVIDADE (UML) ..................................................................... 94.1 CONCEITOS USADOS NOS DIAGRAMAS DE ATIVIDADES ......................... 9


2/10

4.2 ESTADO DE ATIVIDADE E ESTADO DE AO ........................................... 10

4.3 EXEMPLO DE DIAGRAMA DE ATIVIDADE .................................................. 11

5 NORMALIZAO DO DIAGRAMA ENTIDADE RELACIONAMENTO (MRN) ... 12

5.1 MODELO ENTIDADE RELACIONAMENTO (MER) ....................................... 12

5.2 DIAGRAMA ENTIDADE-RELACIONAMENTO (DER) .................................... 125.3 NORMALIZAO ........................................................................................... 13

5.4 DER NORMALIZADO ..................................................................................... 15

6 CONCLUSO .................................................................................................... 16

REFERNCIAS ......................................................................................................

17

1 INTRODUO

Hoje os servios disponibilizados para uma infinidade de situaes esto mudando

cada vez mais para a plataforma WEB, isso ocorre devido a facilidade que essa

plataforma proporciona. Porm, nem sempre, as aplicaes desenvolvida para

essa plataforma atendem os requisitos bsicos de segurana da informao,

confiabilidade da informao e disponibilidade da informao. Nesse trabalho,

alm de abordarmos esse pontos, tambm falaremos de diagramas de atividade e

normalizao de um Diagrama de Entidade Relacionamento.

2 OBJETIVO

Este trabalho tem por objetivo levar o aluno a conhecer os problemas bsicos que

ocorrem no desenvolvimento de aplicaes WEB, tendo como foco a segurana nodesenvolvimento de aplicaes WEB. Os conceitos bsicos de um Diagrama de

Atividade e suas caractersticas e a Normalizao de dados no Diagrama Entidade

Relacionamento.

3 Segurana no desenvolvimento de Aplicaes Web

Atualmente as vulnerabilidades nas aplicaes web so o maior

vetor para os ataques contra a segurana de TI. Os artigos no noticirio acerca

dos ataques que comprometem os dados confidencias frequentemente mencionam

o mtodo usado sendo cross-site scripting, SQL injection e erros deconfiguraes de websites. Muitas vezes as vulnerabilidades deste tipo esto fora

da experincia tradicional dos administradores de segurana de TI. Esta relativa

obscuridade das vulnerabilidades dos aplicaes web faz deles alvos atrativos

para atacantes. Como muitas organizaes tm descoberto, esses ataques

evadiro as defesas tradicionais das redes empresariais, e novas defesas so

necessrias. As vulnerabilidades das aplicaes web em geral tem origem em

configuraes com falhas ou em erros de programao nas linguagens usadas

para aplicaes web (Java, .NET, PHP, Python, Perl, Ruby, etc.). Estas

vulnerabilidades podem ser complexas e podem se manifestar em muitassituaes diferentes.


3/10

A segurana das aplicaes, principalmente aquelas conectadas

a uma rede aberta perigosa como a Internet. Essa complexidade advm do

fato que as aplicaes web so agrupamentos bastante heterogneos de

plataformas, bancos dedados, servidores de aplicao, etc. Uma aplicao tpica,geralmente, est distribuda em vrios servidores, rodando diversos aplicativos e

para funcionar na velocidade adequada, a aplicao precisa que as interfaces

entre os diversos sistemas sejam construdas com a premissa que os dados

passados atravs da mesma so confiveis e no hostis. No h tempo hbil para

duplas verificaes nas aplicaes e a necessidade de haver confiana entre os

diversos subsistemas e disso que os hackers e outros ciber criminosos se

aproveitam. Para o sistema aplicativo, frequentemente desenvolvido in house ou

por terceiros, especificamente para a empresa, no existem patches de segurana.

Segundo o Gartner, 75% dos ataques so concentrados nos aplicativos

especficos de cada empresa, pois os atacantes sabem das suas fragilidades.

3.1 Vulnerabilidades comuns

Nestes sistemas complexos, a segurana dos produtos disponveis no mercado

assegurada pelos fabricantes, que fornecem periodicamente patches que os

atualizam.

Os ataques que hoje conhecemos so baseados em vulnerabilidades tpicas de

aplicaes web complexas. Mesmo os sistemas operacionais que so mantidospor grandes empresas, empregando milhares de profissionais, tm

vulnerabilidades que so periodicamente descobertas por hackers e s se

transformam em patches depois que os hackers j atacaram algumas vezes, que o

problema foi comunicado ao fabricante e devidamente corrigido.

A Internet agregou outros componentes de risco, sendo muito importante o efeito

comunidade em que os hackers e outros criminosos se julgam fazendo parte de

uma comunidade e obrigados a compartilhar rapidamente suas descobertas. Isto

significa que qualquer vulnerabilidade descoberta nas suas aplicaes serrapidamente divulgada, com as ferramentas necessrias para atac-la, e outros

hackers e cibe criminosos aproveitaro as vulnerabilidades da sua aplicao. Os

ataques podem causar uma srie de problemas, entre os quais se podem citar: Perdas Financeiras;

Transaes Fraudulentas;

Acesso no autorizados a dados, inclusive confidenciais;

Roubo ou modificao de Dados;

Roubo de Informaes de Clientes;

Interrupo do Servio; Perda da confiana e lealdade dos clientes; Dano imagem da marca.


4/10

Os tipos mais comuns de ataques so: Cross-Site Scripting

SQL Injection

Command Injection

Cookie/Session Poisoning

Parameter/Form Tampering

Buffer Overflow

Directory Traversal/Forceful Browsing

Cryptographic Interception

Cookie Snooping;

Authentication Hijacking

3.2 Utilizaes de firewalls e protocolo HTTPS.

3.2.1 FIREWALLS

A maioria dos firewalls de rede, por se concentrar nas camadas mais baixas, no

protege as aplicaes da maior parte desses ataques, protege sim o acesso aos

recursos de rede.

Uma nova gerao de appliances est surgindo para resolver este e outrosproblemas, o Aplicativo Firewalls.

Fazem parte de um novo conceito, que a defesa na camada de aplicao.

Defesa das aplicaes dos clientes, no padronizadas, heterogneas, distribudas

em vrios sistemas operacionais, usando diversos servidores de aplicao e debancos de dados.

Surgiram s agora, por duas razes, primeiro a necessidade de combater ataques

cada vez mais inteligentes e segundo a disponibilidade da tecnologia necessria

para a criao desses appliances que necessitam monstruosa capacidade de

computao.

O Gartner Group identificou como uma tendncia transformao do firewallcomuns em commodities, em que a principal diferena entre os diversosappliances o preo, pois as funcionalidades e a tecnologia so bastante

similares, e o surgimento de novos lderes no Gartner Quadrante Mgico dos

Firewall.

3.2.2 HTTPS:

Hypertext Transfer Protocol Secure, uma implementao do protocolo HTTP's

sobre uma camada adicional de segurana que utiliza o protocolo SSL/TLS. Essa

camada adicional permite que os dados sejam transmitidos atravs de umaconexo criptografias e que se verifique a autenticidade do servidor e do cliente


5/10

atravs de certificados digitais. A porta TCP usada por norma para o protocolo

HTTPS a 443.

O protocolo HTTPS utilizado, em regra, quando se deseja evitar que a

informao transmitida entre o cliente e o servidor seja visualizada por terceiros,como, por exemplo, no caso de compras on-line. A existncia na barra de tarefas

de um cadeado (que pode ficar do lado esquerdo ou direito, dependendo do

navegador utilizado) demonstra a certificao de pgina segura (SSL). A existncia

desse certificado indica o uso do protocolo HTTPS e que a comunicao entre o

browser e o servidor se dar de forma segura. Para verificar a identidade do

servidor necessrio abrir esse certificado com um duplo clique no cadeado para

exibio do certificado.

Nas URL's dos Sites o incio ficaria 'https://'. Consulte a ajuda do seu navegador

para mais informaes de como ele avisa sobre sites seguros. Um exemplo de

conexo via HTTPS so os prprios sites da Wikipdia, em que possvel acessar

e editar o contedo dos sites atravs de uma conexo segura. Atravs da URL

possvel editar a Wikipdia em lngua Portuguesa.

Conexes HTTPS so frequentemente usadas para transaes de pagamentos na

World Wilde Web e para transaes sensveis em sistemas de informao

corporativos. Porm, o HTTPS no deve ser confundido com o menos utilizado

protocolo "Secure HTTP" (S-HTTP), especificado na RFC 2660.

4 Diagrama de Atividade (UML)

Um diagrama de atividade essencialmente um grfico de fluxo, mostrando o fluxo

de controle de uma atividade para outra e sero empregados para fazer a

modelagem de aspectos dinmicos do sistema. Na maior parte, isso envolve a

modelagem das etapas sequenciais em um processo computacional; Enquanto os

diagramas de interao do nfase ao fluxo de controle de um objeto para outro,

os diagramas de atividades do nfase ao fluxo de controle de uma atividade para

outra; Uma atividade uma execuo no atmica em andamento em umamquina de estados e acabam resultando em alguma ao, formada pelas

computaes atmicas executveis que resultam em uma mudana de estado do

sistema ou o retorno de um valor.

O Diagrama de atividade um diagrama definido pela Linguagem de Modelagem

Unificada (UML), e representa os fluxos conduzidos por processamentos.

essencialmente um grfico de fluxo, mostrando o fluxo de controle de uma

atividade para outra. Comumente isso envolve a modelagem das etapas

sequenciais em um processo computacional.


6/10

Os diagramas de atividade no so importantes somente para a modelagem de

aspectos dinmicos de um sistema ou um fluxograma, mas tambm para a

construo de sistemas executveis por meio de engenharia de produo reversa.

4.1 Conceitos Usados nos Diagramas de Atividades Atividades: Comportamento a ser realizado.

Sub-atividade: Execuo de uma sequncia no atmica de atividades.

Transio: Fluxo de uma atividade para outra.

Ao: Transformao.

Deciso: Dependendo de uma condio, mostra as diferentes transies.

Raia: Diferenciao de unidades organizacionais.

Bifurcao (Fork): Separa uma transio em vrias transies executadasao mesmo tempo.

Sincronizao (Join): Concatenao de transies vindas do Fork.

Objeto: O objeto da atividade.

Envio de sinal: Transio pra um meio externo, por exemplo, um hardware. Recepo de sinal: Recepo do envio.

Regio: Agrupamento de uma ou mais atividades.

Exceo: Atividades que ocorrerem em decorrncia de uma exceo.

Os diagramas de atividade costumam conter: Estado de atividade e estado de ao.

Transies

Objetos

4.2 Estado de atividade e estado de ao

No fluxo de controle modelado por um diagrama de atividade

onde as atividades acontecem. possvel calcular uma expresso que defina um

conjunto de valor de um atributo ou que retorne algum valor. Alternativamente,

voc poder chamar uma operao num objeto, enviar um sinal a um objeto ou at

criar ou destruir um objeto. Estas computaes atmicas executveis so

chamados estado de ao.

Os estados de ao no podem ser decompostos. Alm disso, os estados de ao

so atmicos, significando que os eventos podero ocorrer, mas o trabalho de

estado de ao no interrompido. O trabalho de estado de ao geralmente

considerado como ocupando um tempo de execuo insignificante.

Em contraste, os estados de atividade podem ser decompostos, suas atividades

sendo representadas por outros diagramas de atividades. Alm disso, os estados

de atividade so no-atmicos, significando que podero ser interrompidos e, em

geral, so considerados como tomando algum tempo para serem completados.4.3 Exemplo de Diagrama de Atividade


7/10

5 Normalizao do Diagrama Entidade Relacionamento (MRN)

5.1 Modelo entidade relacionamento (MER)

Em engenharia de software, um modelo entidade relacionamento (modelo ER) um modelo de dados para descrever os dados ou aspectos de informao de um

domnio de negcio ou seus requerimentos de processo, de uma maneira abstrata

que em ltima anlise se presta a ser implementada em um banco de dados, como

um banco de dados relacional. Os principais componentes dos modelos ER so

entidades (coisas) e os relacionamentos que podem existir entre eles, e bancos de

dados.

Um modelo entidade relacionamento uma maneira sistemtica de descrever e

definir um processo de negcio. O processo modelado como componentes

(entidades) que so ligadas umas s outras por relacionamentos que expressam

as dependncias e exigncias entre elas, como: um edifcio pode ser dividido em

zero ou mais apartamentos, mas um apartamento pode estar localizado em

apenas um edifcio. Entidades podem ter vrias propriedades (atributos) que os

caracterizam. Diagramas criados para representar graficamente essas entidades,

atributos e relacionamentos so chamados de diagramas entidade relacionamento.

Um modelo ER normalmente implementado como um banco de dados. Nos

casos de um banco de dados relacional, que armazena dados em tabelas, as

prprias tabelas representam as entidades. Alguns campos de dados nestastabelas apontam para ndices em outras tabelas. Tais ponteiros representam

relacionamentos.

5.2 Diagrama Entidade-Relacionamento (DER)

O Diagrama Entidade-Relacionamento descreve toda estrutura lgica do banco de

dados. possvel constru-lo a partir de um MER, identificando assim a partir de

um conceito do mundo real como os dados sero armazenados de fato.

O DER tem como nfase os dados e os relacionamentos. Sua representao

utiliza os smbolos:

Retngulos - representam as entidades;

Elipses - representam os atributos;

Losangos - representam os relacionamentos entre as entidades;

Linhas - unem os atributos aos conjuntos de entidades e os conjuntos de


8/10

entidades aos conjuntos de relacionamentos;

Elipses duplas - atributos multivalorados.

Na construo de um projeto de banco de dados necessrio saber quais so osobjetos e os relacionamentos para elaborar o DER, ou seja, descobrir quais os

atributos que compem as tabelas (objetos).

5.3 Normalizao

A utilizao do MER nos proporciona a criao de um DER (Diagrama de

Entidades e Relacionamento). Os DER fazem uma representao de parte de um

mundo real onde so feitas representaes estruturadas e conceituais do que o

ser humano pode fazer nessa parcela do mundo real.

A princpio, Peter Chen props como notao desses diagramas os retngulos

como sendo as entidades, os losangos como sendo os relacionamentos entre as

entidades, os crculos como sendo os atributos das entidades e linhas de conexo

para mostrar a cardinalidade entre uma entidade e outra.

Ao aplicar esse sistema de Relacionamento, existem uma srie de passos para

fazer com que os dados tornem-se menos redundantes e menos inconsistentes.

Tais passos so chamados de Normalizao de dados. A primeira forma normal foi

definida por Edgar F. Codd em 1970. Essa norma tinha como definio permitirque os dados fossem questionados e manipulados usando uma "sub-linguagem de

dados universal" atrelada lgica de primeira ordem. Nem sempre essa

normalizao eficiente, dependendo da separao entre o projeto lgico da base

de dados e a implementao fsica do banco de dados.

Para normalizao feito um trabalho sobre as restries que indicam relaes

individuais, isto , as restries relacionais. O propsito destas restries

descrever o universo relacional, ou seja, o conjunto de todas as relaes que so

permitidas para serem associadas com certos nomes de relao. Dentre essasrestries relacionais, a mais importante a Chave, a qual vai relacionar um

registro com um ou mais valores de ndice.

Existem hoje diversas normas formais, cada uma gerando aprimoramentos em

relao norma anterior. Abaixo as normas e definies:

Primeira Norma Formal: Uma tabela est na 1FN, se e somente se, no possuir

atributos multivalor.

Segunda Norma Formal: Uma relao est na 2FN se, e somente se, estiver na


9/10


10/10

(http://www.guilhermepontes.eti.br/sgbd/revisao.pdf) Acesso em: 19 de outubro de

2014.

MACORATTI.NET, .NET - Implementando Solues OOP II. Disponvel em:

(http://www.macoratti.net/11/09/net_ioop2.htm) Acesso em: 19 de outubro de 2014.

OWASP.ORG, As 10 vulnerabilidades de segurana mais crticas em aplicaes

WEB. Disponvel em:

(https://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf) Acesso

em: 19 de outubro de 2014.

SITEBLINDADO.COM, Segurana Para aplicaes Web. Disponvel em:

(http://www.siteblindado.com/pt/pags/view/files/WhitePaper+QualysGuard+Vulnera

bility+Web+Applications.pdf) Acesso em: 19 de outubro de 2014.

WIKIPEDIA, Diagrama de atividade. Disponvel em:

(http://pt.wikipedia.org/wiki/Diagrama_de_atividade) Acesso em: 19 de outubro de

2014.

WIKIPEDIA, Modelo entidade relacionamento. Disponvel em:

(http://pt.wikipedia.org/wiki/Modelo_entidade_relacionamento) Acesso em: 19 de

outubro de 2014.

Documents

Portfolio Individual 4° Semestre ADS UNOPAR 2014