DEV Community: Rayane Pimentel

Exercício Prático – Aplicando Conceitos de Segurança desde o Início

Rayane Pimentel — Tue, 20 May 2025 15:45:35 +0000

Cenário:

Você faz parte de uma equipe que está iniciando o desenvolvimento de uma nova plataforma chamada Voluntariamos, que conecta pessoas voluntárias a eventos sociais e instituições solidárias. A plataforma terá funcionalidades como:

Cadastro de pessoas voluntárias
Cadastro de eventos
Inscrição em eventos
Avaliação das ações após a participação

Tarefa 01

Sua tarefa:
Com base no que foi discutido sobre SSDLC, execute as atividades abaixo:

1. Identificação de Dados Sensíveis e Pessoais (Fase: Requisitos de Segurança):
Liste os dados que serão coletados das pessoas usuárias da plataforma. Classifique-os como:

Dados pessoais
Dados sensíveis (conforme a LGPD)

Ex: Nome completo, CPF, localização, preferências de voluntariado, etc.

2. Ameaças e Riscos Iniciais (Fase: Arquitetura e Design):
Escolha uma funcionalidade da plataforma (por exemplo, o login, ou o cadastro de eventos). Responda:

Quais ameaças podem surgir nesse componente?
Quais vulnerabilidades podem ser exploradas?
Qual o risco se essa vulnerabilidade for explorada?

3. Estratégias de Mitigação (Fase: Arquitetura e Design):
Para as ameaças/vulnerabilidades identificadas acima, proponha ao menos duas estratégias de mitigação utilizando princípios de segurança discutidos:

Segurança por design
Autenticação e autorização
Criptografia
Firewalls ou outras barreiras

4. Reflexão Final:

Por que é importante pensar em segurança desde o início do desenvolvimento?

Tarefa 02

1. Identificação de Dados Sensíveis e Pessoais

Liste os dados coletados e classifique-os como pessoais ou sensíveis. Justifique brevemente com base no impacto de um vazamento.

Exemplo: Certificado de vacinação → Sensível (revela estado de saúde).

2. Modelagem de Ameaças com STRIDE

Escolha a funcionalidade de inscrição em eventos. Para cada categoria do STRIDE, identifique:

Uma ameaça possível.
Vulnerabilidade relacionada.
Risco associado.

(S)poofing, (T)ampering, (R)epudiation, (I)nformation Disclosure, (D)enial of Service, (E)levation of Privilege

3. Mitigações Técnicas e Processuais

Para uma das ameaças identificadas, proponha:

Uma mitigação técnica (ex: criptografia).
Uma mitigação processual (ex: treinamento de usuários).

4. Caso de Teste de Segurança

Projete um teste para validar se a mitigação técnica funciona. Inclua:

Ferramenta utilizada (ex: Snyk para verificar dependências, Semgrep/Horusec para analise de vulnerabilidade).
Cenário de teste (ex: injeção de SQL no formulário de inscrição).

SSDLC – Manutenção

Rayane Pimentel — Tue, 20 May 2025 15:20:36 +0000

A manutenção é a fase onde a segurança se torna um ciclo contínuo. Aqui, a aplicação já está em produção, mas novas ameaças surgem diariamente, atualizações são lançadas e vulnerabilidades podem ser descobertas. O objetivo é monitorar, corrigir e evoluir o sistema.

Monitoramento Contínuo

O sistema deve registrar e analisar atividades suspeitas, como:
Múltiplas tentativas de login falhas por uma aluna - possível tentativa de força bruta.

Uma professora tentando acessar dados pessoais de alunas, o que viola as regras de acesso definidas.
Acessos administrativos feitos fora do horário comercial ou de IPs desconhecidos.

Esses registros são auditados e utilizados para:

Detecção de comportamento.
Acompanhamento de incidentes de segurança.
Ativação de alertas automáticos com base em padrões definidos.

Atualizações e Correções

Aplicação de patches de segurança em bibliotecas e dependências.
Atualizações regulares do sistema operacional e da aplicação.
Reforço das configurações de segurança (como headers HTTP, senhas de serviço, etc.).

Resposta a Incidentes

Um plano de resposta deve estar definido:
Revogação de tokens de sessões suspeitas.
Suspensão temporária de contas com comportamento suspeito. Notificação à equipe de segurança e, se necessário, aos usuários afetados.

Exemplo:

Se a aluna tentar alterar dados que não pertencem a ela, o sistema deve bloquear a ação, registrar o evento e notificar a equipe.
Se a professora tentar acessar dados de alunas fora de sua turma, um alerta deve ser gerado.

Auditoria e Logs

Todos os acessos e alterações relevantes devem ser registrados e armazenados, como previsto nos requisitos.

A administradora tem acesso ao painel de auditoria para:
Verificar quem editou notas.
Confirmar acessos a dados sensíveis.
Garantir que apenas pessoas autorizadas visualizaram ou alteraram informações.

Cultura de Segurança Contínua

Treinamentos:

Para Devs
Para Professores/Administradores: Orientar sobre uso responsável de privilégios (com base no nosso exemplo).

Simulações:
Testar a equipe com cenários de phishing ou vazamento de dados para reforçar boas práticas.

Na manutenção, a segurança é um processo contínuo e proativo. Não basta corrigir falhas reativas é preciso:

Monitorar para detectar ameaças em tempo real.
Atualizar para mitigar vulnerabilidades conhecidas.
Treinar para manter a equipe preparada.
Revisar para garantir que padrões de segurança não se degradem com o tempo.

SSDLC – Implantação Segura (Deploy)

Rayane Pimentel — Tue, 20 May 2025 15:15:59 +0000

A fase de implantação é onde a aplicação é preparada para entrar em produção. No SSDLC, esse estágio não se trata apenas de garantir que todos os controles de segurança definidos nas etapas anteriores sejam implementados e validados antes da liberação para os usuários finais.

Deploy seguro: Garantir que o processo de deploy siga práticas seguras, como a proteção de pipelines de CI/CD e a implementação de controles de acesso ao ambiente de produção.

Checklist de segurança: Uma checklist de segurança antes do deploy, incluindo a validação de configurações e testes finais.

Exemplo: Antes de colocar a versão online, a equipe verifica:
Se variáveis sensíveis (como JWT_SECRET, DATABASE_URL) estão setadas via ambiente seguro.

Se todas as APIs de professoras têm o controle correto de permissões, impedindo que acessem dados pessoais.

Se os headers HTTP como Content-Security-Policy, Strict-Transport-Security e X-Content-Type-Options estão configurados.

Se os tokens JWT expiram corretamente após 30minutos de inatividade, conforme os requisitos de segurança.

Pentest - Profissional que realiza análises detalhadas e avançadas de segurança.

Exemplo: Um pentester interno simula um ataque como se fosse uma professora tentando acessar dados pessoais de alunas via requisição direta: GET /alunas/456/dados-pessoais

Mesmo autenticada como professora, ele consegue visualizar dados como CPF e endereço - o que indica uma falha de autorização não detectada pelos testes automatizados.

Após o pentest, a equipe corrige a lógica de verificação de permissões no backend.

SSDLC – Testes

Rayane Pimentel — Tue, 20 May 2025 15:13:22 +0000

Nesta etapa, o objetivo é validar se os controles de segurança implementados estão funcionando como esperado. Vamos aplicar diferentes tipos de testes, focando tanto no código quanto no comportamento do sistema em execução.

Ferramentas e estratégias de testes utilizados:

DAST (Dynamic Application Security Testing):

Simula ataques reais enquanto a aplicação está rodando (por exemplo, injeção de SQL ou XSS).

Identifica vulnerabilidades que não são visíveis somente no código, como falhas na autenticação, permissões ou exposições de dados.

Exemplo:

Durante um teste DAST, é feita uma tentativa de acesso ao histórico escolar de outra aluna alterando o parâmetro alunaId na URL.
GET /alunas/123/historico

Mesmo autenticada como aluna 456, a requisição retorna os dados da aluna 123, isso indica uma falha grave de controle de acesso, detectada somente em tempo de execução, pois o endpoint não validou corretamente o ID do token JWT.

Code Review com foco em segurança:

Revisão manual ou assistida (com ferramentas como Horusec) para detectar más práticas de codificação, como uso de funções inseguras, falta de validações, exposição de dados sensíveis.

Fundamental para identificar lógicas de negócio inseguras que passam despercebidas em testes automatizados.

Exemplo:

Ao revisar o código, encontra-se um trecho onde a professora pode editar dados pessoais da aluna, mesmo sendo algo que ela não deveria ter permissão:

if (usuario.role === 'professora') {
  atualizarDadosPessoais(alunaId, novosDados); 
}

O code review ajuda a identificar essa lógica insegura de negócio, que permite a edição de dados sensíveis por quem não tem essa permissão.

SSDLC – Implementação

Rayane Pimentel — Tue, 20 May 2025 15:09:47 +0000

Essa é a fase que nós, pessoas desenvolvedoras, iremos atuar continuamente. Assim como arquitetos de software precisam entender sobre segurança, nós também precisamos conhecer sobre desenvolvimento seguro. Se esse conceito é novo para você e você trabalha com desenvolvimento web, recomendo começar pelo OWASP Top 10.

Mas a segurança vai além disso! Também existem outras referências importantes, como:

CWE e CWE Top 25 - Lista de fraquezas comuns de segurança em software.
CERT - Diretrizes para programação segura em diferentes linguagens.
CVE - Base de dados de vulnerabilidades conhecidas em produtos e softwares específicos.

Nesta fase, colocamos a segurança em prática através de código seguro e ferramentas automatizadas.
Já temos o relatório da "Modelagem de ameaças", sabemos quais são as possíveis ameaças e também como mitiga-las.
Também podemos usar a segurança na criação de histórias. Veja um exemplo:

Exemplo de Codificação Segura com OWASP ASVS

O OWASP ASVS (Application Security Verification Standard) é um guia estruturado para validar controles de segurança em aplicações web. Ele pode ser usado como checklist para assegurar que requisitos de segurança estão sendo cumpridos durante a codificação.

No login da plataforma, precisamos proteger contra acesso não autorizado.

Problema: Precisamos proteger o sistema contra acessos não autorizados.
Fonte: ASVS (Application Security Verification Standard)
Seção do ASVS: V3 Gestão de Sessão

Formato da User Story:

Como [tipo de usuário], eu quero [meta ou objetivo] para que [benefício ou resultado]

User Story:

"Como uma pessoa desenvolvedora, eu quero que o sistema expire automaticamente as sessões após 30 minutos de inatividade, para reduzir o risco de acesso não autorizado."

Requisito de Segurança (ASVS):
"O sistema deve expirar automaticamente as sessões após 30 minutos de inatividade, conforme o OWASP ASVS, seção V3 (Gestão de Sessão)."

Comportamento Esperado:
Expiração automática das sessões após 30 minutos de inatividade.

Critério Específico:
A sessão deve ser expirada após 30 minutos de inatividade do usuário.

Referência ao OWASP ASVS:
Seção V3 (Gestão de Sessão) do OWASP ASVS, que trata da gestão segura das sessões e o tempo limite de inatividade.

Implementação em Node.js (Express):

const session = require('express-session');
require('dotenv').config(); // Carrega variáveis de ambiente

app.use(session({
  secret: process.env.SESSION_SECRET, // Chave armazenada em variável de ambiente
  resave: false,
  saveUninitialized: false,
  cookie: { 
    secure: true, // Só transmite via HTTPS
    httpOnly: true, // Impede acesso via JavaScript
    maxAge: 30 * 60 * 1000 // 30 minutos
  }
}));

Esse foi apenas um exemplo simples de como o time pode usar ASVS para criar suas histórias.

Implementação de Ferramentas de Segurança

Nessa fase também implementamos ferramentas de segurança que complementam o desenvolvimento de código seguro como SAST - analisa o código-fonte em busca de vulnerabilidades. Essas ferramentas não são a única solução, mas são aliados poderosos para aumentar a segurança da aplicação. Não podemos depender exclusivamente delas, mas usá-las como um suporte para mitigar vulnerabilidades.

Ferramentas para Automatizar a Segurança:

Análise Estática de Código:
Como SonarQube ou ESLint com regras de segurança para identificar vulnerabilidades durante o desenvolvimento.

Verificação de Dependências:
Como Snyk ou Dependabot para detectar bibliotecas com vulnerabilidades (ex: npm audit).

Implementação SAST no pipeline

main: main é o branch principal da aplicação. É o código estável.
feature: é onde estamos escrevendo nossos códigos
commit: commit das nossas alterações
pull request: estamos enviando uma solicitação para mesclar nossas alterações na main
github action: quando criamos PR ou fazemos um push com github actions configurado, ele é acionado para executar os fluxos de trabalho definidos.
CI: Toda vez que ele foi acionado, ele executa o trabalho: clona o projeto, roda todos os testes, gerar o build(arquivos que você precisa para a aplicação rodar) da aplicação. E também no nosso caso, executa o Horusec. Ou seja, todas as vezes que fizermos um PR, esse processo garante que código de forma segura possa estar integrado na aplicação principal.
horusec: O Horusec é uma ferramenta de segurança que analisa o código em busca de vulnerabilidades de segurança.

Notas:

CVE e CWE: Consulte o CVE MITRE e CWE Top 25 para priorizar correções.
LGPD: Garanta que dados sensíveis sejam criptografados em repouso (ex: PostgreSQL com pgcrypto).
Documentação: Mantenha um registro de decisões de segurança para auditorias futuras.

SSDLC – Arquitetura e Design

Rayane Pimentel — Tue, 20 May 2025 15:00:38 +0000

Com os requisitos de segurança bem definidos, a próxima etapa envolve a elaboração da arquitetura, do design e da estrutura do software, assegurando que ele seja seguro por padrão.

Esse cuidado se alinha ao princípio de Security by Design, onde a segurança é tratada como uma característica essencial desde a concepção da aplicação, e não como um complemento posterior.

Aqui, são tomadas decisões sobre como os componentes interagem, como as camadas de segurança serão aplicadas e como mitigar ameaças conhecidas.

Algumas perguntas a serem respondidas incluem:

Como os serviços serão autenticados entre si? Haverá uso de tokens, certificados ou chaves de API?
Como será feito o processo de transmissão de dados? Será utilizado HTTPS, TLS ou outros mecanismos de criptografia?
Qual será o serviço de nuvem ou servidor web utilizado e como será configurada a segurança?
Existem padrões de segurança já estabelecidos para serem seguidos, como OWASP Top 10 ou NIST?
Qual linguagem será usada (por exemplo, JavaScript, Python, Java)?
Quais frameworks e bibliotecas serão utilizados (por exemplo, NestJS, Angular, Django)?
Qual sistema de gerenciamento de banco de dados será adotado (por exemplo, PostgreSQL, MongoDB)?

Tecnologias Utilizadas

No exemplo, a plataforma foi desenvolvida com Angular para o front-end, NestJS para o back-end, e PostgreSQL para o gerenciamento de dados hospedado em um serviço de nuvem.

Autenticação entre Serviços

A comunicação entre a plataforma (Angular) e o BFF (Backend For Frontend) é realizada por meio de Tokens (JSON Web Tokens). Esses tokens são emitidos pelo Identity Provider após a validação das credenciais (login e senha) da usuária, garantindo que apenas usuários autenticados possam acessar as funcionalidades da aplicação.

Os serviços autenticados incluem:

Plataforma → BFF: A comunicação é feita de forma segura, protegendo dados de login e informações pessoais.
BFF → Identity Provider: O BFF valida as credenciais e obtém o token para autenticação subsequente.
BFF → Servidor de Aplicação: O BFF encaminha a requisição ao servidor de aplicação, utilizando o token para assegurar que a solicitação seja de um usuário autenticado.

Transmissão de Dados

Protocolo: A transmissão de dados entre os componentes da plataforma é realizada utilizando HTTPS, garantindo que a comunicação seja criptografada.
Mecanismo de Criptografia: TLS/SSL é usado entre o servidor de aplicação e o banco de dados (hospedado em um serviço de nuvem).

Firewalls

Entre o BFF e o servidor de aplicação, são implementados firewalls para atuar como barreiras de proteção. Esses firewalls filtram o tráfego e protegem o servidor de aplicação contra acessos não autorizados e ataques externos.

Modelagem de ameaça

Nessa etapa, também realizamos a modelagem de ameaças para identificar possíveis ameaças e ataques, além de desenvolver estratégias para mitigá-las.

Exemplo simples:

O que pode dar errado? Aqui identificamos possíveis ameaças.
O que você deve fazer em relação a essas ameaças? Com uma lista de ameaças identificadas, o próximo passo é desenvolver estratégias para mitiga-las.

Exemplo de Mitigação:

Alvo: Login (alguém se passando por outro usuário)
Estratégia de Mitigação: Identificação e autenticação de login (o sistema sabe/tem)
Técnica de Mitigação: Senha, Tokens e MFA

Uma técnica comum para modelagem de ameaças é o modelo STRIDE, que classifica ameaças em categorias como Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service e Elevation of Privilege. Se você quiser saber mais sobre como modelagem de ameaça, eu escrevi sobre aqui.

Usaremos a Modelagem na ameaça na próxima fase.

SSDLC – Requisitos de segurança (planejamento)

Rayane Pimentel — Tue, 20 May 2025 14:58:47 +0000

Nessa fase, são definidos os requisitos de segurança, funcionais e não funcionais, como as regras que devem ser seguidas, incluindo normas como a LGPD. Além disso, as decisões tomadas aqui influenciam diretamente a arquitetura e o design do sistema, garantindo que a segurança seja considerada desde a estruturação inicial.

Algumas perguntas importantes a serem respondidas incluem:

Qual é a classificação dos dados de acordo com as políticas da empresa? Isso inclui dados pessoais e sensíveis, e deve ser especificado como cada tipo de dado será tratado.
Quem terá acesso aos dados? Detalhar quem tem permissão para visualizar, alterar ou excluir os dados, com base nas políticas de controle de acesso.
Políticas de Exclusão: Devemos definir e documentar políticas claras para a exclusão de dados, incluindo como e quando os dados devem ser removidos.

Por exemplo, no nosso sistema, temos dados pessoais e acadêmicos das alunas. Quem terá permissão para ver esses dados? Quem pode alterá-los? Quais são as políticas de exclusão aplicadas?

Na imagem, podemos ver que a aluna possui dados pessoais (nome, CPF, endereço, data de nascimento) e dados acadêmicos (notas, RA, frequência e histórico escolar).

Nota Importante:
Devemos lembrar que, na classificação de dados, existem os dados sensíveis, que são aqueles que revelam origem racial ou étnica, convicções religiosas ou filosóficas, opiniões políticas, filiação sindical, informações genéticas, biométricas, sobre a saúde ou a vida sexual de uma pessoa, conforme estabelecido pela LGPD.

Dados pessoais: são aqueles que permitem a identificação direta ou indireta de uma pessoa.
Dados sensíveis: dentro dos dados pessoais, os dados sensíveis requerem maior cuidado durante a coleta e o tratamento, pois estão diretamente relacionados aos aspectos mais íntimos da personalidade do cidadão.

Voltando ao exemplo, a aluna tem acesso apenas aos seus próprios dados(pessoais e acadêmicos), enquanto a professora tem acesso de visualização e também de edição apenas aos dados acadêmicos de suas alunas, podendo, por exemplo, alterar notas ou incluir justificativas para faltas. Já a administradora tem acesso a todos os dados pessoais, acadêmicos e administrativos de todos os usuários.

Segurança no Desenvolvimento – SSDLC

Rayane Pimentel — Tue, 20 May 2025 14:58:04 +0000

Para começarmos a entender o que é SSDLC (Secure Software Development Life Cycle), trouxe uma analogia para vocês. Eu sempre penso em como explicaria algo novo para a minha avó. Então, vamos à analogia e depois à explicação com exemplos.
Analogia: Casa

Análise de Requisitos (Planejamento): Nesta fase, você identifica os materiais e requisitos legais necessários para construir a casa, como consultar a prefeitura sobre regras e normas de construção.

Arquitetura e Design: Você desenha a planta da casa, escolhendo materiais, planejando entradas e saídas, e definindo medidas de segurança, como alarme e fechaduras.

Implementação: A casa começa a ser construída. Você percebe que, além do alarme, precisa adicionar câmeras para garantir mais segurança.

Testes: Antes de entregar a casa, a equipe testa o funcionamento das instalações, como eletricidade, alarmes e janelas. Verifica se tudo está em ordem.

Implantação: Antes de entregar a casa aos proprietários, engenheiros fazem uma análise para garantir que tudo foi construído corretamente. Se estiver tudo certo, a casa é entregue.

Manutenção: A casa está funcionando, mas você precisa fazer manutenções regulares. O alarme ou câmeras podem precisar de atualizações ou trocas devido a falhas descobertas.

Bom, agora vamos ao SSDLC :)

SSDLC

Como vimos na analogia o SSDLC pode ser considerado uma construção de uma casa, com um Lego, onde cada fase do processo de desenvolvimento de software seguro é uma peça importante que, quando combinada com as outras, forma um software seguro.

Ou seja, devemos pensar em segurança desde o início, já no planejamento, e não apenas a partir da codificação. A segurança deve estar presente em todas as fases do ciclo de desenvolvimento.
Nosso foco está na prevenção de vulnerabilidades desde o começo e na promoção de uma mudança cultural dentro das equipes de desenvolvimento.

Agora, vamos entender como funciona cada fase desse ciclo.

Segurança no Desenvolvimento: Da Teoria à Prática – Introdução

Rayane Pimentel — Tue, 20 May 2025 14:57:38 +0000

Pensando em segurança no desenvolvimento de software, onde geralmente a incluímos? Como pessoa desenvolvedora, posso pensar na fase de codificação, testes e implementação. Mas, se pensarmos um pouco antes, será que o início do desenvolvimento do software é na codificação? Não, sabemos que a codificação não é o começo. Então, por que não pensar e incluir segurança desde o início?
Como incorporar segurança desde o começo, antes mesmo da codificação? Por que vulnerabilidades conhecidas, como XSS e SQL Injection, ainda estão presentes em software?

SQL Injection teve sua primeira identificação em 1998. Fonte: https://phrack.org/issues/54/8.html

Exemplo de report SQL Injection de julho de 2024. Fonte: https://hackerone.com/reports/2597543

Para responder a essas questões, vamos entender como funciona SSDLC (Secure Software Development Life Cycle) e como ele pode ser aplicado tanto em novos projetos quanto em softwares em desenvolvimento.
Antes de entrarmos em SSDLC, vamos entender alguns conceitos importantes.

Vulnerabilidade, Ameaça e Risco

No exemplo, temos uma página de login com os campos "username" e "password". Um agente mal-intencionado (a ameaça) deseja acessar o sistema para obter dados ou privilégios que ele não deveria ter. Ele pode tentar explorar brechas de segurança conhecidas. Quando ele encontra uma falha de segurança por exemplo no login (a vulnerabilidade), ele explora essa falha.

Se o agente consegue acessar o sistema, o risco não é só o ato de acessar o sistema em si, mas sim a possibilidade de que a ameaça explore a vulnerabilidade e cause um impacto negativo, como roubo de dados, comprometimento do sistema, ou controle total, especialmente se ele conseguir fazer login como administrador. O risco acontece quando uma vulnerabilidade é explorada, e o impacto desse risco varia conforme o tipo de acesso obtido (por exemplo, um login de administrador representa um risco maior para a empresa).

A vulnerabilidade é o ponto fraco que pode ser explorado por uma ameaça, resultando em risco de danos ao sistema.

Parte I.III Operadores Lógicos

Rayane Pimentel — Sat, 07 Aug 2021 21:35:14 +0000

Operadores Lógicos

O Javascript suporta 3 operadores lógicos, que são aplicadas aos valores booleanos(true e false).
São: &&, || ou ! ou AND, OR, ou NOT

Operador &&(AND) o valor é true, se ambos os dados fornecidos forem true;
Operador ||(OR) o valor é true, se uns dos dados fornecidos for true;
Operador !(NOT), operador de negação, inverte o valor dado a ele - !true produz false e !false produz true.

Exemplo:

Caso hipotético: Para participar de um curso de programação, você precisa ter 18 anos ou mais e morar em São Paulo.

Nós temos duas condições, você precisa ter 18 anos ou mais AND morar em São Paulo, ou seja os dois dados fornecidos precisam serem true. Se sim, você pode participar(true), caso contrário não(false).

se idade >= 18 && cidade == "São Paulo"
 "Maravilha, você pode participar do curso"
senão
  "Poxa, infelizmente você não tem todos os critérios"

Para continuarmos, você precisa entender o conceito de if else o se senão do nosso caso hipotético.

Definição MDN

"A condicional if é uma estrutura condicional que executa a afirmação, dentro do bloco, se determinada condição for verdadeira. Se for falsa, executa as afirmações dentro de else."

Sintaxe

if (condição) afirmação1 [else afirmação2]

Exemplo:
Hoje vai fazer frio?
Se sim, preciso de casaco;
Senão, não preciso de casaco.

let tempoHoje = "frio";

if(tempoHoje == "frio") {
  console.log("preciso de casaco");
}else {
  console.log("não preciso de casaco");
}

Mas o tempo de São Paulo é louco (rs) e pode fazer frio e calor no mesmo dia, como poderíamos fazer isso utilizando if else?

let tempoHoje = "frio&Calor";

if(tempoHoje == "frio") {
  console.log("preciso de casaco");
}else if(tempoHoje == "frio&Calor"){
  console.log("Use roupas leves, mas leve casaco");
}else{
 console.log("Use roupas leves");
}

Agora que você já entende como funciona o if else, vamos praticar com os operadores lógicos. Mas antes disso, vamos de revisão.

Operador && (AND) e operador || (OR)

a	b	a && b	a \|\| b
true	true	true	true
true	false	false	true
false	true	false	true
false	false	false	false

Operador ! (NOT)

a	!a
true	false
false	true

Exemplos

Já fizemos alguns exemplos com &&, mas a pratica é essencial.

let num1 = 3;
let num2 = 10;

if(num1 >= 15 && num2 >= 4 {
 console.log(true);
else {
 console.log(false)
}

No exemplo o retorno será false, já que num1 não é maior ou igual 15. E para ser true, precisamos que as duas informações sejam true

Agora o mesmo exemplo, mudando o operador && por ||

let num1 = 3;
let num2 = 10;

if(num1 >= 15 || num2 >= 4 {
 console.log(true);
else {
 console.log(false)
}

Com || (OR), o retorno será true, já que para ser true só precisamos de uma informação verdadeira.
num1 é não é maior ou igual a 15 (false), mas num2 é maior ou igual a 4 (true), por isso o retorno true.

Utilizando o operador ! (NOT) Como já sabemos o operador !, inverte o valor, se for true será false, e se for false será true.

Basicamente isso:

let a = 2
let b = 5

if(!a == 2 && b == 5) {
 console.log(true)
else {
 console.log(false)
}

O retorno será false.
Vamos analisar, sabemos que a = 2 e b = 5
na condição !a == 2, a == 2 é true, mas como a tem o operador de negação ! -> !a inverte e true torna false.
Então !a == 2 é false
e b == 5 é true

Só que temos outro operador lógico, o &&, como também sabemos para o retorno ser true, precisamos que os dois sejam true. E no nosso exemplo só b é true e a é false.

Exercício

Agora que já entendemos como funciona os operadores lógicos e if else, vamos aos exercícios

1 - Pergunte ao usuário a sua idade, certifique de receber apenas números inteiros
2 - Retorne se ele já tem idade para votar ou não
3 - Crie um joguinho com dois participantes, pergunte para ambos "Olá, diga um número qualquer de 0 - 10"
Depois retorne quem informou o maior número, se ambos informaram o mesmo número ou se teve algum que não informou um número válido entre 0 e 10

Link do Exercício

Parte I.II Operadores

Rayane Pimentel — Sat, 07 Aug 2021 21:34:29 +0000

Operadores

Operadores Aritméticos

São os operadores que já conhecemos:

[+] adição - adiciona números

let a = 10;
let b = 3;
let soma = a + b; //13

[-] subtração - subtrai números

let a = 10;
let b = 3;
let subtrai = a - b; //7

[*] multiplicação - multiplica números

let a = 10;
let b = 3;
let multiplica = a * b; //30

[/] divisão - divide números

let a = 10;
let b = 5;
let divide = a / b; //2

[%] modulo - devolve o resto da divisão.

let a = 10;
let b = 4;
let resto = a % b; //2

[++] incremento - incrementa números.

let a = 10;
a++;
let b = a; //11

[--] decremento - diminui números.

let a = 10;
a--;
let b = a; //9

[**] exponenciação - calcula a base elevada a potência do expoente

let a = 2;
let b = 3;
let resultado = 2 ** 3; //8

Operadores de Comparação

Faz uma comparação entre valores e/ tipos e retorna true ou false.
É como se vocês estivesse perguntando:

isso é `operador de comparação` a aquilo?
- Sim (true)
ou
- Não (false}

[>] maior ou [<] menor

let a = 10;
let b = 5;

let conferir = a > b; // true
let conferirNovamente = a < b; //false

[>=] maior ou igual ou [<=] menor ou igual

let a = 10;
let b = 5;
let c = "10"

let conferir = a >= b; // true
let conferirNovamente = a <= b; //false
let resultado = a >= c; //true
let porqueEIgual = a <= c; //true

[==] igualdade - compara se os valores são iguais(true)

let a = 10;
let b = 5;
let c = "10";

let conferir = a == b; //false
let conferirNovamente = a == c; //true

[!=] compara se os valores são diferentes

let a = 10;
let b = 5;
let c = "10";

let conferir = a != b; //true
let conferirNovamente = a != c; //false

[===] igualdade - compara se os valores e os tipos são iguais

let a = 10; //tipo number e valor 10
let b = 5; //tipo number e valor 5
let c = "10" //tipo string e valor 10
let d = 5; //tipo number e valor 5

let conferir = a === b; //false
//a e b são do tipo number, mas valores diferentes
let conferirNovamente = a === c; //false
// a e c são tipos diferentes, mas com o mesmo valores
let resultado = b === d; //true
// b e c são do mesmo tipo e tem o mesmo valor

[!==] diferente - compara se os valores ou os tipos são diferentes

let a = 10; //tipo number e valor 10
let b = 5; //tipo number e valor 5
let c = "10" //tipo string e valor 10
let d = 5; //tipo number e valor 5

let conferir = a !== b; //true
//a e b são do tipo number, mas valores diferentes
let conferirNovamente = a !== c; //true
// a e c são tipos diferentes, mas com o mesmo valores
let resultado = b !== d; //false
// b e c são do mesmo tipo e tem o mesmo valor

Exercício

Como vimos podemos fazer várias comparações. O que você acha que acontecerá se comparamos o menor ou o maior utilizando string?

"teste" > "javascript";
"abc" < "def";

Se você não entendeu o que aconteceu, veja essa explicação
Explicação

Parte I.I - Tipos de dados

Rayane Pimentel — Tue, 27 Jul 2021 00:38:22 +0000

Tipos de dados

O que são?

Tudo o que escrevemos em javascript é um tipo de dado.
Exemplo:

13
"olá"
true

Quais são os tipos?

String: É uma sequência de zero ou mais caracteres escritos entre aspas simples ' ' ou dupla " "

let issoAquiE = "Uma string";

let issoAquiTambem = "13";

number variável tipada com número e sem "aspas".

let idade = 13;
let pesoDaBanana = 1.250

Em javascrip number por ser inteiro int ou flutuante float.

let idade = 13; //int
let pesoDaBanana = 1.250 //float

booleans retorna se o valor é verdadeiro true ou falso false. Exemplo:

let valorUm = 10
let valorDois = 9

let maiorOuMenor = valorUm > valorDois 

console.log(maiorOuMenor)//true

let valorIgual = valorDois == 20

console.log(valorIgual)//false

~~~ Pequena pausa ~~~
Como sabemos tudo o que estiver entre "aspas" é string, mesmo números dentro de " ", são string.
Dica para saber qual tipo de dado utilizamos typeof(nomeDaVarivel)

let myVar = "Olá Mundo!"
let kids = 10

console.log(typeof(myVar))//string
console.log(typeof(kids))//number

let myVar1 = "13"
console.log(typeof(myVar1))//string

~~~ Fim da pausa ~~~

undefined: é quando declaramos uma variável sem valor.

let myStr;

console.log(typeof(myStr));//undefined

array* com array podemos armazenar vários valores em uma única variável, como se fosse uma lista, ao invés de declarar item por item, você declara todos em uma única variável.

let semana = ["Domingo", "Segunda", "Terça", "Quarta", "Quinta", "Sexta", "Sábado"];

No exemplo let semana todos itens era uma string, mas você pode armazenar vários tipos em uma mesma array.
Exemplo, uma array pode ter string, number, boolean...

let sequence = [1, 1, 2, 3, 5, 8, 13];
let  random = ['tree', 795, [0, 1, 2]];

object é uma associação de propriedades com nome (chave) e valor. Exemplo. quando declaramos um carro ou uma pessoa.

const person = {firstName: "Olivia", lastName: "Benson", age:57};

//chave seria firstName, lastName e age
//valor seria: "Olivia", "Benson" e 57

const car = {type:"Fiat", model:"500", color:"white"};

p.s: não se preocupe, esse primeiro momento pode ser que fique confuso, mas depois abordaremos mais sobre os tipos de dados e como podemos trabalhar com eles.

Exercício

1 - Pergunte ao usuário qual a idade dele.
Certifique de receber só números inteiros, mesmo que o usuário digite número flutuante

2 - Crie uma nova variável, que irá receber a idade do usuário e verifica se é maior que 18 e exiba no console.log()

3- Depois exiba pro usuário a seguinte mensagem:
"Olá usuário a sua idade é xxx"
xxx será o valor da idade do usuário.

Link do Exercício parte I.I