Desarrollo seguro: OWASP

Recientemente, he estado repasando los cursos que hay online, en universidades y en otras entidades sobre desarrollo seguro, viendo que casi todos se centran en OWASP (Open Web Application Segurity Project), lo cual está muy bien, pero se quedan en hablar del Top 10 de vulnerabilidades, y en realidad hay mucho más.
security photo

Está muy bien saber cómo se puede originar un fuego, pero es mucho más importante saber cómo actuar en cada caso o cómo se puede evitar que el fuego llegue a iniciarse ¿no? Con la seguridad en el desarrollo pasa lo mismo.

En el PDF que resume las vulnerabilidades, se pueden ver unos anexos con las responsabilidades de cada perfil (manager, developer y tester), y una pequeña guía para que una organización sea  segura. Esos anexos son muy importantes, puesto que nos ayudarán a ver si estamos haciendo las cosas bien o no.

Y bien, sabiendo los problemas que pueden surgir y la responsabilidad de cada uno para tener una empresa que practique desarrollo seguro ¿qué hacemos? Llegamos al que para mi es uno de los compendios más importantes que realiza este proyecto: OWASP Proactive Controls. En él se resumen las buenas prácticas que hay que realizar para funcionar de un modo seguro y evitar la mayoría de los incendios. Este es su propio Top 10:

  1. Verificar la seguridad pronto y a menudo
  2. Parametrizar las queries
  3. Codificar los datos
  4. Validar todas las entradas
  5. Implementar controles de autenticación y de identidad
  6. Implementar controles de acceso apropiados
  7. Proteger los datos
  8. Implementar logging y detección de intrusos
  9. Aprovechar frameworks y librerías de seguridad
  10. Manejo de errores y excepciones

¿Pones todos esos puntos en práctica? Sé que puede parecer difícil, pero profundizando un poco más, podréis ver que tienen también guías específicas de cómo hacerlo con cada tecnología, porque no es lo mismo estar haciendo una app para Android, que una web en PHP, y siguiéndolas podréis de un modo sencillo aseguraros de que estáis poniendo todo de vuestra parte para que vuestros desarrollos sean seguros.

Get to the point with Solidity

As I explained in my previous post about coding for Ethereum, there are a lot of ways to learn Solidity. However, most of them are really humdrum if you already know how to code, almost if you know javascript. So, let’s get to the point with Solidity looking the simplest structures you need to start coding.

ethereum photo

Solidity is based on javascript, but it also owns structures from other functional languages like Haskell and from object-oriented languages like Java. To do Dapps you need more than knowing the language because you need to know about patterns, security, how to compile and publish, and what actions cost more gas than others. Also, Solidity owns more reserved words than the explained below and more complex structures like inserting assembly inline, but with a little base of javascript and reading the following script (just 242 lines) you will be ready to start the backend of your very own distributed application over the Ethereum Virtual Machine.

pragma solidity ^0.4.19; //Version of the compiler

import "./otherContractsFile.sol";

contract ContractName { //Declaration of the basic unit of code
   /***Variables and funtions***/
   bool boolVariable;
   uint unsignedIntVariable;
   int intVariable;
   int intVariableWithValue = 10;
   uint16 unsigned16BitInt;
   uint256 unsignedIntVariable2;
   ufixed unsignedFixedVariable;
   fixed128x19 fixedVariableWith128bitsAnd19DecimalPoints;
   string stringVariable = "It can store any UTF-8 encoded string";
   address addressVariable; //addresses are used to store user accounts and contracts identifiers
   var aVariable = intVariableWithValue; //aVariable is defined as an int variable
   uint constant lustrum = 5 years;

   /*State variables are permanently stored in the EVM
    *between external function calls for this contract. 
    */
   uint stateVariable;

   function doSomething(uint uintParam) {
      /*Variables declared inside functions
       *are stored in memory and they are reset 
       *between different calls to the function.
       */
      uint functionVariable;
      
      functionVariable++;
      stateVariable = stateVariable + functionVariable;
      /*functionVariable = 1
       *stateVariable = 1 the first time this function is executed,
       *2 the second time this functions is executed, 3 the third, ...
       */
   }

   /***Collections and your own types***/
   uint[2] fixedArray;
   uint[] dynamicArray;
   mapping (address => uint) mapFromAddressToUint;

   enum EnumType {
      FirstValue,
      SecondValue,
      ThirdValue
   }

   struct StructType {
      uint uintField;
      string stringField;
   }
   StructType structVariable;
   StructType structVariableWithValue = StructType(10, "something");
   StructType[] structArray;

   function manageStructArrayByValue() {
      /*This variable is asigned by value (a copy is done)*/
      StructType memory myStruct = structArray[0]; 
      myStruct.uintField = 10; //structArray[0].uintField = 0;
   }

   function manageStructArrayByReference() {
      /*This variable is asigned by reference (a pointer is created)*/
      StructType storage myStruct = structArray[0]; 
      myStruct.uintField = 10; //structArray[0].uintField = 10;
   }

   uint[] public publicArray; //A public array is read-only publicly accessible by other contracts
   mapping (uint => string) public publicMap;

   function workWithArrays() private {
      uint[] myArray;
      myArray.push(1); //myArray = [1]
      myArray.push(2); //myArray = [1,2]
      uint newLenth = myArray.push(1); //newLenth = 3, myArray = [1,2,1] 
   }

   /*Functions are public by default, so you need to set them private
    *in order to keep your contract secure. In other case, functions
    *can be called (and executed) by other contracts.
    */
   function doSomethingPrivate(uint uintParam) private {
      //some code
   }

   /*Internal functions are functions that can be called from
    *contracts that inherit from this one.
    */
   function doSomethingInternal(uint uintParam) internal {
       //some code
   }

   /*Public functions can be called from anywhere.*/
   function do(uint param) public {
      //some code
      doSomethingPrivate(param);
      doSomethingInternal(unsignedIntVariable);
      doSomethingPrivate(10); //Can't call to doSomethingExternal
   }

   /*External functions can be called from external contracts
    *but not from inside this contract.
    */
   function doSomethingExternal(uint param) external {
      //some code
   }

   function ContractName() public { //this is a constructor but be carefull using them, they are not executed in some special cases
      //do something
   }

   function return10() returns (uint) {
      return 10;
   }

   function returnMultipleValues() returns (uint value1, uint value2) {
      value1 = 10;
      value2 = 20;
   }

   function returnMultipleValues2() returns (uint, uint) {
      return(10, 20);
   }

   function useMultipleValues() {
      uint value1;
      uint value2;
      (value1, value2) = returnMultipleValues();

      uint value4;
      (,value4) = returnMultpleValues2();
   }

   /*function throwsAnError(int a) private returns (int8) {
    *   return a + 1;
    *}
    */

   function addAndConvert(int a) private returns (int8) {
      return int8(a) + 1; //uses the 8 less significant bits of a
   }

   function addAndConvertIfIsInt8(uint a) private returns (uint8) {
      require(a <= 2 ** 8); //Throws an error if false
      return uint8(a) + 1;
   }

   /***Events***/
   event sthOccurred(uint param);

   function throwEvent() private {
      sthOcurred(10);
   }

   /***Modifiers***/
   //"view" can be used to identify functions that are not changing any data
   function returnInt() public view returns (int) {
      return intVariable;
   }

   //"pure" can be used to identify functions that do not access any data in the contract
   function add(int a, int b) public pure returns (int) {
      return a + b;
   }

   //"payable" is needed in order to receive Ether with a call
   function aFunctionThatCost() public payable {
      //this contract will own the ether sended at the end of the execution
   }

   modifier myModifier() {
      //some code to be executed before the function
      _; //this is a placeholder that indicates the point where the code of the function will be executed
      //some code to be executed after the function
   }

   function functionWithModifier() public myModifier {
      //some code to be executed in the place where the placeholder is set inside modifier's code
   }

   function otherFunctionsAndValues() private {
      keccak256("qwerty"); //returns a 256-bit hexadecimal with a SHA3 hash of the param
      //"qwerty" == "QWERTY"; Solidity can't compare strings. Instead you can do
      keccak256("qwerty") != keccak256("QWERTY");

      uint currentUnixTimestamp = now;
      1 minutes == 60;
      1 hours == 3600;
      //you also have available "days", "weeks" and "years" units

      address currentBlocMiner = block.coinbase;
      uint currentBlockDifficulty = block.difficulty;
      uint currentBlockGasLimit = block.gaslimit;
      uint currentBlockNumber = block.number; 
      uint currentBlockUnixTimestamp = block.timestamp;
      bytes32 theHash = block.blockhash(block.number); //only works for 256 most recent blocks excluding current
      bytes completeCallData = msg.data;
      uint remainingGas = msg.gas;
      address callerWhoInitiatesThisExecution = msg.sender;
      bytes4 firstFourBytesOfMsgData = msg.sig;
      uint numberOfWei = msg.value;
      uint gasPriceOfTheTransaction = tx.gasprice;
      uint senderOfTheTransaction = tx.origin;

      assert(1==2); //like require but for internal errors
      revert(); //abort and revert changes
   }

}

/***Inheritance and rehusability***/
contract A {
   function aFunction {}
}

contract B is A {
   function bFunction {
      aFunction();
   }
}

/*If you want to use an external contract, you need to define an
 *interface with the definition of the methods that you want to
 *use.
 */
contract InterfaceOfExternalContract {
   function functionExternalDefinition(uint param) external return (uint);

   function functionPublicDefinition(uint param) public return (uint);
}

contract ContractWichUsesTheExternalContract {
   address externalContractAddress = 0x...;
   InterfaceOfExternalContract externalContract = InterfaceOfExternalContract(externalContractAddress);

   function aFunction() {
      uint value = externalContract.functionExternalDefinition(1);
   }
}

And now, what are you starting to code?

Como empezar a programar apps distribuidas en Solidity para Ethereum

Podría parecer que para programar Dapps, las aplicaciones que corren sobre la máquina virtual de Ethereum, es necesario ser un experto en blockchain, saber de criptografía, entender cómo se calculan los hash de los bloques, entender cómo está implementado el Proof of Work, o incluso saber cómo se mina. Sin embargo, no hace falta profundizar tanto para echar a andar una aplicación distribuida, veamos por dónde se puede empezar.

learn photo

Para desarrollar Dapps, basta con conocer cómo funciona la Ethereum Virutal Machine, conocer las arquitecturas y patrones que se emplean y manejarse con alguno de los lenguajes pensados para tal fin. El más popular es Solidity, que está basado en javascript, aunque hay otros como LLL (que está basado en Lisp) o Serpent (basado en Python).

Para aprender a programar con Solidity se puede empezar por muchos sitios. Puedes empezar a dar vueltas por el Wiki de Ethereum, o ir directamente a la documentación oficial, aunque personalmente creo que es un poco tediosa y no va demasiado al grano. Otra opción es buscar un buen tutorial en el que te enseñen paso a paso, como Cryptozombies que te enseña a hacer desde cero un juego como el popular Cryptokitties.

Para aprender el lenguaje cualquiera de esas vías es válida. Sin embargo,  por desgracia, creo que es necesario pasar por todas esas documentaciones para tener conocimiento de los patrones más habituales y estar preparado para hacer cualquier tipo de aplicación, ya que si por ejemplo te quedas en ver cómo está hecho Cryptokitties, sólo conocerás aquellos que sirven para hacer un sistema de compraventa de bienes únicos.

Es cierto que esto puede llevar mucho tiempo, y si tienes prisa por empezar a programar, puedes buscar un curso para que alguien te guíe y te dé información concisa y bien estructurada. Recientemente he empezado a colaborar con DevAcademy, una academia que ofrece cursos de alto nivel para las tecnologías más punteras (DevOps, Machine Learning, Big Data, …) y, cómo no, entre ellos tiene un curso de Solidity. Es una buena alternativa para que te lo den todo mascado, y además, le puedes pedir a tu empresa que te lo pague ya que le saldrá gratis por ser formación bonificada. Si quieres saber más sobre este u otro de sus cursos, no dudes en ponerte en contacto conmigo y que podamos ver tus necesidades o las de tu empresa.

Intelgate: ¿qué ha pasado? ¿Cómo te afecta?

Hace unos días que nos encontramos con una sobredosis de noticias sobre el «caso de Intel», con gritos de alarma sobre lo malo que es y todo lo que nos va a perjudicar. Vamos a ver de un modo sencillo qué es lo que ha pasado y cómo nos afectará.

Meltdown photo
Photo by Kenneth Dagenais

¿Qué ha pasado?

Se han hecho públicos unos bugs que afectan a los procesadores (los chips principales de los ordenadores). En concreto, estos bugs se aprovechan del funcionamiento de los procesadores que como son muy rápidos, muy rápidos, a veces se inventan el código a ejecutar para ganar tiempo. Una aplicacion que se aprovechase de estos bugs, podría «incitar» al procesador a leer partes de memoria a la que no debería tener acceso.

Uno de ellos (Meltdown) afecta casi exclusivamente a procesadores Intel, y afecta a casi todos los procesadores de Intel de la última década. Este bug es una feature de estos procesadores, que resulta que es un poco insegura y que cuando se implementó, nadie se paró a pensar que se podría usar así. Este bug ya tiene un sistema que permite corregirlo, pero que afecta al rendimiento del procesador.

Los otros dos (Spectre) afectan a la mayoría de procesadores habituales, y al parecer va a ser más difícil de corregir.

Esto no es todo. La polémica, y el motivo de que se comparase con el caso de los diesel de Volkswagen, es la actitud de Intel en su tratamiento. Lo sabían desde hace tiempo y lo mantenían oculto. Además han seguido vendiendo y sacando nuevos modelos afectados por dichos bugs. El CEO vendió todas las acciones que pudo, aprovechándose de su conocimiento privilegiado. Además, tras hacerse público, se han dedicado a tirar balones fuera negando lo evidente y señalando a otras empresas con el dedo.

¿Cómo te afecta?

Suponiendo que eres un usuario normal, te afecta poco.

El parche que se empezó a distribuir, efectivamente afecta al rendimiento del procesador, pero afecta sólo en un caso muy concreto en el que las aplicaciones necesitan hacer llamadas especiales que controla el sistema operativo como por ejemplo leer un archivo. La mayoría de aplicaciones hacen esto de manera ocasional y esto, sumado a que casi todos los sistemas domésticos suelen tener el procesador infrautilizado, conlleva que apenas vayas a notar ningún cambio en el ordenador de tu casa.

Por tanto, los sistemas que se van a ver más penalizados son los dedicados a virtualización, bases de datos, etc. Principalmente los sistemas corporativos y entornos cloud, que suelen tener cargas más altas y sufren mayores cambios de contexto, serán los que se vean más afectados. Dicen que estos sistemas se harán entre un 5% y un 30% más lentos, y las pruebas que se han realizado con sistemas de este estilo así lo avalan.

Además de esto, Google anunció un modo de parchear los sistemas, que reduciría sustancialmente los problemas derivados de su aplicación, haciendo que lo que se ralenticen sea practicamente insignificante, pero habrá que ir viendo a medida que se vaya aplicando.

Resumen:

Se ha encontrado un problema histórico, que si se hubiese tratado con normalidad y explicado con sinceridad, no habría supuesto tanta alarma. Sin embargo, la negativa de Intel a afrontarlo, ha provocado un caos y una desinformación que les pasará factura más pronto que tarde.

 

APIs públicas para tus proyectos

Año nuevo: proyecto nuevo. Estoy seguro de que sois muchos los que estáis empezando un sideproject como propósito para el nuevo año. A la hora de elegir la mejor idea, si no queréis picar un montón de código, os vendrá bien saber que APIs tenéis disponibles para juntarlas, remezclarlas y sacar alguna funcionalidad chula.

API photo
Photo by abraham.williams

Es muy importante saber qué herramientas tienes disponibles, y es un conocimiento que además os puede venir muy bien para enfocar mejor esos momentos de desorden en el que vienen un montón de ideas a la cabeza.

Pero, no corráis a poneros a buscar en Google «API pública», por favor. Hay maneras de optimizar el tiempo para que todo lo que dediquéis sea de experimentación y absorción de conocimiento. Además, si optáis por la primera opción, es muy posible que os encontréis que cada una está definida y documentada como su padre y su madre han creído oportuno: puede ser una auténtica locura.

Hay gente que ya se ha encargado de juntar un montón de definiciones de APIs públicas, de tal modo que tu las tengas a mano y ordenadas. Además, así puedes acceder a todas de una misma forma y tener la documentación de una forma más estandarizada.

Para cacharrear con ellas puedes hacerlo como prefieras: desde la web; con un sdk para tu plataforma preferida; o incluso desde la línea de comandos. Sin embargo, si me pedís la recomendación más cómoda (aunque por el momento es la que menos APIs tiene disponibles) yo optaría por una colección para el postman, que es una extensión de Chrome que me tiene enamoradito desde hace años.

Ánimo, elegid vuestro sabor preferido y dadle vida a ese nuevo proyecto.