security posts - idmontie's Portfolio

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    h2: "h2",
    strong: "strong",
    a: "a",
    pre: "pre",
    code: "code"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "The crypto craze has died down, but if you are working on Smart Contracts or thinking about creating a new blockchain projects, security is a huge part of making sure the project is successful. Since Smart Contracts often interact with cryptocurrencies, blockchain assets, or other tokens, it’s important to make sure the Smart Contract is secure and follows best practices."
    }), "\n", _jsx(_components.p, {
      children: "In general, the best practices around Smart Contracts are the same for writing secure code in general."
    }), "\n", _jsx(_components.h2, {
      children: "Keep it Simple"
    }), "\n", _jsx(_components.p, {
      children: "Keep your Smart Contract code simple. Smart Contracts that try to be too clever often have unintended side-effects or functionality. Keeping a Smart Contract simple also means that the surface area for attacks is smaller."
    }), "\n", _jsx(_components.h2, {
      children: "Write Small Functions"
    }), "\n", _jsx(_components.p, {
      children: "Write small functions that do one thing. Many Smart Contracts will have many small functions that can be composed together, rather than one large function that does everything. This helps keep the code readable, making it easier to understand and secure."
    }), "\n", _jsx(_components.h2, {
      children: "Linting"
    }), "\n", _jsx(_components.p, {
      children: "Lint your code. Smart Contracts written in Solidity have tools already written that can help catch common errors via linting. The easiest linters to set up just help improve formatting, but some can help you write more secure code by letting your know when functions have been deprecated or marked as insecure."
    }), "\n", _jsx(_components.h2, {
      children: "Unit Tests"
    }), "\n", _jsxs(_components.p, {
      children: ["Unit test your code. The best unit tests you can write for Smart Contracts are validating what users shouldn’t be able to do. As an example, make sure unauthorized accounts cannot withdraw assets from your contract. These are sometimes called ", _jsx(_components.strong, {
        children: "negative"
      }), " tests and they can be even more important than your typical that validate your functions do what you expect them to do. These tests check that they fail in the correct way when misused."]
    }), "\n", _jsx(_components.h2, {
      children: "Scan for Security Vulnerabilities"
    }), "\n", _jsx(_components.p, {
      children: "Scan your code for security vulnerabilities. This is pretty self-explanatory. Many Smart Contract toolchains provide scanning tools to check your Smart Contract code."
    }), "\n", _jsxs(_components.p, {
      children: ["There are a few ways to surface security issues in Ethereum Smart Contracts. One way is to use ", _jsx(_components.a, {
        href: "https://github.com/crytic/slither",
        children: "slither"
      }), ":"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-tsx",
        children: "npm install slither\nslither .\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "This may take a while to run, but it will scan the compiles contracts for security issues."
    }), "\n", _jsx(_components.h2, {
      children: "Compliance"
    }), "\n", _jsxs(_components.p, {
      children: ["For Ethereum Smart Contracts, you can also use ", _jsx(_components.a, {
        href: "https://github.com/crytic/slither",
        children: "slither"
      }), " to check the compliance of your ERC20 token or ERC721 contracts. Running this check will verify that your contract implements the expected interfaces of the given contracts."]
    }), "\n", _jsx(_components.h2, {
      children: "Wrapping it Up"
    }), "\n", _jsx(_components.p, {
      children: "Security is a major consideration in any application, but Smart Contracts pose a new type of attack vector for malicious users. Smart Contracts often interact with pools of cryptocurrency, NFTs, and other blockchain assets that make them new targets for attackers. It’s important when writing Smart Contracts to always make sure the contract fails correctly, even more-so than completing actions successfully."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>The crypto craze has died down, but if you are working on Smart Contracts or thinking about creating a new blockchain projects, security is a huge part of making sure the project is successful. Since Smart Contracts often interact with cryptocurrencies, blockchain assets, or other tokens, it’s important to make sure the Smart Contract is secure and follows best practices.</p>
<p>In general, the best practices around Smart Contracts are the same for writing secure code in general.</p>
<h2>Keep it Simple</h2>
<p>Keep your Smart Contract code simple. Smart Contracts that try to be too clever often have unintended side-effects or functionality. Keeping a Smart Contract simple also means that the surface area for attacks is smaller.</p>
<h2>Write Small Functions</h2>
<p>Write small functions that do one thing. Many Smart Contracts will have many small functions that can be composed together, rather than one large function that does everything. This helps keep the code readable, making it easier to understand and secure.</p>
<h2>Linting</h2>
<p>Lint your code. Smart Contracts written in Solidity have tools already written that can help catch common errors via linting. The easiest linters to set up just help improve formatting, but some can help you write more secure code by letting your know when functions have been deprecated or marked as insecure.</p>
<h2>Unit Tests</h2>
<p>Unit test your code. The best unit tests you can write for Smart Contracts are validating what users shouldn’t be able to do. As an example, make sure unauthorized accounts cannot withdraw assets from your contract. These are sometimes called <strong>negative</strong> tests and they can be even more important than your typical that validate your functions do what you expect them to do. These tests check that they fail in the correct way when misused.</p>
<h2>Scan for Security Vulnerabilities</h2>
<p>Scan your code for security vulnerabilities. This is pretty self-explanatory. Many Smart Contract toolchains provide scanning tools to check your Smart Contract code.</p>
<p>There are a few ways to surface security issues in Ethereum Smart Contracts. One way is to use <a href="https://github.com/crytic/slither">slither</a>:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code class="language-tsx">npm install slither
slither .
</code></pre></div>
<p>This may take a while to run, but it will scan the compiles contracts for security issues.</p>
<h2>Compliance</h2>
<p>For Ethereum Smart Contracts, you can also use <a href="https://github.com/crytic/slither">slither</a> to check the compliance of your ERC20 token or ERC721 contracts. Running this check will verify that your contract implements the expected interfaces of the given contracts.</p>
<h2>Wrapping it Up</h2>
<p>Security is a major consideration in any application, but Smart Contracts pose a new type of attack vector for malicious users. Smart Contracts often interact with pools of cryptocurrency, NFTs, and other blockchain assets that make them new targets for attackers. It’s important when writing Smart Contracts to always make sure the contract fails correctly, even more-so than completing actions successfully.</p>


The crypto craze has died down, but if you are working on Smart Contracts or thinking about creating a new blockchain projects, security is a huge part of making sure the project is successful. Since Smart Contracts often interact with cryptocurrencies, blockchain assets, or other tokens, it’s important to make sure the Smart Contract is secure and follows best practices.

In general, the best practices around Smart Contracts are the same for writing secure code in general.

## Keep it Simple

Keep your Smart Contract code simple. Smart Contracts that try to be too clever often have unintended side-effects or functionality. Keeping a Smart Contract simple also means that the surface area for attacks is smaller.

## Write Small Functions

Write small functions that do one thing. Many Smart Contracts will have many small functions that can be composed together, rather than one large function that does everything. This helps keep the code readable, making it easier to understand and secure.

## Linting

Lint your code. Smart Contracts written in Solidity have tools already written that can help catch common errors via linting. The easiest linters to set up just help improve formatting, but some can help you write more secure code by letting your know when functions have been deprecated or marked as insecure.

## Unit Tests

Unit test your code. The best unit tests you can write for Smart Contracts are validating what users shouldn’t be able to do. As an example, make sure unauthorized accounts cannot withdraw assets from your contract. These are sometimes called **negative** tests and they can be even more important than your typical that validate your functions do what you expect them to do. These tests check that they fail in the correct way when misused.

## Scan for Security Vulnerabilities

Scan your code for security vulnerabilities. This is pretty self-explanatory. Many Smart Contract toolchains provide scanning tools to check your Smart Contract code.

There are a few ways to surface security issues in Ethereum Smart Contracts. One way is to use [slither](https://github.com/crytic/slither):

```tsx
npm install slither
slither .
```

This may take a while to run, but it will scan the compiles contracts for security issues.

## Compliance

For Ethereum Smart Contracts, you can also use [slither](https://github.com/crytic/slither) to check the compliance of your ERC20 token or ERC721 contracts. Running this check will verify that your contract implements the expected interfaces of the given contracts.

## Wrapping it Up

Security is a major consideration in any application, but Smart Contracts pose a new type of attack vector for malicious users. Smart Contracts often interact with pools of cryptocurrency, NFTs, and other blockchain assets that make them new targets for attackers. It’s important when writing Smart Contracts to always make sure the contract fails correctly, even more-so than completing actions successfully.


Smart Contract Security

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    h2: "h2",
    a: "a",
    strong: "strong",
    ul: "ul",
    li: "li",
    pre: "pre",
    code: "code",
    blockquote: "blockquote"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "This post was originally on a blog I started for creating web applications. This post goes into security for web applications."
    }), "\n", _jsx(_components.h2, {
      children: "Prevent Against SQL Injection"
    }), "\n", _jsxs(_components.p, {
      children: ["Read about ", _jsx(_components.a, {
        href: "http://en.wikipedia.org/wiki/SQL_injection",
        children: "SQL injection"
      }), " and learn how to prevent it for the langauge and database you are using."]
    }), "\n", _jsx(_components.h2, {
      children: "All User Input is Filtered"
    }), "\n", _jsx(_components.p, {
      children: "Never trust user input.  This includes cookies and hidden form field values."
    }), "\n", _jsx(_components.h2, {
      children: "Read the Open Web Application Security Project"
    }), "\n", _jsxs(_components.p, {
      children: ["Read ", _jsx(_components.a, {
        href: "https://www.owasp.org/index.php/Category:OWASP_Guide_Project",
        children: "the Open Web Application Security Project"
      }), "."]
    }), "\n", _jsx(_components.h2, {
      children: "All Passwords are Hashed with a Salt"
    }), "\n", _jsxs(_components.p, {
      children: ["Hash all passwords using a ", _jsx(_components.a, {
        href: "http://security.stackexchange.com/q/21263/396",
        children: "salt"
      }), " and all salts are different to prevent against ", _jsx(_components.a, {
        href: "http://en.wikipedia.org/wiki/Rainbow_table",
        children: "rainbow attacks"
      }), "."]
    }), "\n", _jsxs(_components.p, {
      children: ["The hashing algorithm should be bcrypt or scrypt for storing passwords.  Look into ", _jsx(_components.a, {
        href: "http://codahale.com/how-to-safely-store-a-password/",
        children: "How To Safely Sroe a Password"
      }), "."]
    }), "\n", _jsxs(_components.p, {
      children: ["Do ", _jsx(_components.strong, {
        children: "not"
      }), " use MD5 or any SHA algorithm.  SHA algorithms are meant to be fast, which should not be used for trying to securely store passwords."]
    }), "\n", _jsx(_components.h2, {
      children: "Use a Standard Authentication System"
    }), "\n", _jsx(_components.p, {
      children: "Do not role your own authentication system."
    }), "\n", _jsx(_components.h2, {
      children: "Process Credit Card Information Correctly"
    }), "\n", _jsxs(_components.p, {
      children: ["Look into the ", _jsx(_components.a, {
        href: "https://www.pcisecuritystandards.org/",
        children: "PCI Security Standards"
      }), " for financial security information."]
    }), "\n", _jsx(_components.h2, {
      children: "Use HTTPS for Sensitive Data"
    }), "\n", _jsxs(_components.p, {
      children: ["Set up your ", _jsx(_components.a, {
        href: "http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt",
        children: "SSL"
      }), "/", _jsx(_components.a, {
        href: "http://en.wikipedia.org/wiki/Https",
        children: "HTTPS"
      }), " certs correctly and check it against ", _jsx(_components.a, {
        href: "https://www.ssllabs.com/ssltest/",
        children: "SSL Labs Server Test"
      }), "."]
    }), "\n", _jsx(_components.h2, {
      children: "Prevent Session Hijacking"
    }), "\n", _jsx(_components.p, {
      children: "Built in session systems are usually premade to handle these types of attacks. It is not recommended that you roll your own, but it should have the following features:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "Encrypted data traffic.  The session key in particular should be encrypted, but ideally all traffic should be encrypted by using SSL/TLS."
      }), "\n", _jsx(_components.li, {
        children: "Long random session key.  Attackers should not be able to guess valid session keys."
      }), "\n", _jsxs(_components.li, {
        children: ["Regenerating the session id after a successful login.  Prevents [session fixation](", _jsx(_components.a, {
          href: "http://en.wikipedia.org/wiki/Session_fixation%5D",
          children: "http://en.wikipedia.org/wiki/Session_fixation]"
        }), "."]
      }), "\n", _jsx(_components.li, {
        children: "Change the cookie value with each and every request.  This reduces the window for an attacker to hijack the session."
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "Prevent Cross Site Scripting (XSS)"
    }), "\n", _jsxs(_components.p, {
      children: ["Unfiltered query parameters that are added to the DOM are an easy way for attackers to use cross site scripting to pull data from your users.  Filter all query parameters; see ", _jsx(_components.a, {
        href: "http://en.wikipedia.org/wiki/Cross-site_scripting",
        children: "Cross-site Scripting"
      }), " for more information on common attacks and prevention methods."]
    }), "\n", _jsx(_components.h2, {
      children: "Prevent Page Embedding"
    }), "\n", _jsx(_components.p, {
      children: "You can prevent page embedding with the following header:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        children: "X-Frame-Options: DENY\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "This will cause browsers to refuse requests for framing in that page."
    }), "\n", _jsxs(_components.p, {
      children: ["You can also prevent page embedding with JavaScript to prevent users from accessing your website in an iframe.  Look into this ", _jsx(_components.a, {
        href: "http://stackoverflow.com/questions/7776281/javascript-jquery-how-to-detect-if-a-page-is-embedded-by-others",
        children: "StackOverflow solution"
      }), "."]
    }), "\n", _jsx(_components.h2, {
      children: "Prevent Cross Site Request Forgeries"
    }), "\n", _jsx(_components.p, {
      children: "Cross site request forgeries are attacks by a malicious user whereby they craft a link to a site which a user is know to have been authenticated.  For example, say your site is a bank website; the malicious user may craft a URL for you site that when a user clicks on it, deposits money into the attacker's account.  The attacker then sends the link to users who may have been logged into your bank website."
    }), "\n", _jsxs(_components.p, {
      children: ["According to ", _jsx(_components.a, {
        href: "http://en.wikipedia.org/wiki/Cross-site_request_forgery",
        children: "Wikipedia"
      }), ":"]
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user's web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action."
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "Prevent Click Jacking"
    }), "\n", _jsxs(_components.p, {
      children: ["Similar to ", _jsx(_components.a, {
        href: "#prevent-page-embedding",
        children: "Page Embedding"
      }), ", click jacking works by:"]
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "A user might receive an email with a link to a video about a news item, but another valid page, say a product page on Amazon.com, can be \"hidden\" on top or underneath the \"PLAY\" button of the news video. The user tries to \"play\" the video but actually \"buys\" the product from Amazon."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "Other known exploits include:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "Tricking users into enabling their webcam and microphone through Flash"
      }), "\n", _jsx(_components.li, {
        children: "Tricking users into making their social networking profile information public"
      }), "\n", _jsx(_components.li, {
        children: "Making users follow someone on Twitter[8]"
      }), "\n", _jsx(_components.li, {
        children: "Sharing links on Facebook"
      }), "\n"]
    }), "\n", _jsxs(_components.p, {
      children: ["See ", _jsx(_components.a, {
        href: "http://en.wikipedia.org/wiki/Clickjacking",
        children: "Wikipedia"
      }), " for more information."]
    }), "\n", _jsx(_components.h2, {
      children: "Verify That Server Software is Up to Date"
    }), "\n", _jsx(_components.p, {
      children: "Make sure that the software on your system is up to date with the latest patches."
    }), "\n", _jsx(_components.h2, {
      children: "Verify That Packages, Modules, Plugins, etc are Up to Date"
    }), "\n", _jsx(_components.p, {
      children: "Make sure that the latest software used by your projest is up to date with the latest patches."
    }), "\n", _jsx(_components.h2, {
      children: "Verify That Your Database is Secured"
    }), "\n", _jsx(_components.p, {
      children: "Make sure that connections to the database are at least password protected.  Verify that only the least amount of permissions are being used."
    }), "\n", _jsx(_components.p, {
      children: "Make sure that confidential information is encrypted or hashed."
    }), "\n", _jsx(_components.h2, {
      children: "Attempt to Make Your App Run As Non-Root"
    }), "\n", _jsxs(_components.p, {
      children: ["Apply ", _jsx(_components.a, {
        href: "https://en.wikipedia.org/wiki/Principle_of_least_privilege",
        children: "the principle of least privilege"
      }), " and try to have your app run as non-root as often as possible."]
    }), "\n", _jsx(_components.h2, {
      children: "Use the Content-Security-Policy Header"
    }), "\n", _jsx(_components.p, {
      children: "Specify the following header to make the browser only run certain content depending on its origin:"
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.strong, {
        children: "example"
      })
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        children: "Content-Security-Policy: script-src 'self' https://apis.google.com\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "You can also specify the following type of content:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "script-src (JavaScript)"
      }), "\n", _jsx(_components.li, {
        children: "connect-src (XMLHttpRequest, WebSockets, and EventSource)"
      }), "\n", _jsx(_components.li, {
        children: "font-src (Fonts)"
      }), "\n", _jsx(_components.li, {
        children: "frame-src (Frame Urls)"
      }), "\n", _jsx(_components.li, {
        children: "img-src (Images)"
      }), "\n", _jsx(_components.li, {
        children: "media-src (Audio and Videos)"
      }), "\n", _jsx(_components.li, {
        children: "object-src (Flash)"
      }), "\n", _jsx(_components.li, {
        children: "style-src (CSS)"
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "Do Not Allow Mime Sniffing with User Uploaded Content"
    }), "\n", _jsx(_components.p, {
      children: "You can tell browsers to not try to guess Mime Types of files with the following header:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        children: "X-CONTENT-TYPE-OPTIONS: nosniff\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "For example, say a user uploads an HTML file. You intend to serve it to users as a text file, but the browser will attempt to serve it as an HTML page.  You can tell the browser that you know what you are doing and that the Mime Type you are providing is indeed correct by using the above header."
    }), "\n", _jsx(_components.h2, {
      children: "Force HTTPS Traffic"
    }), "\n", _jsx(_components.p, {
      children: "You can force HTTPS Traffic with the following header:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        children: "Scrict-Transport-Security: max-age=31536000; includeSubDomains\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["This will force ", _jsx(_components.code, {
        children: "https://website.com"
      }), " even when typing in ", _jsx(_components.code, {
        children: "http://website.com"
      })]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>This post was originally on a blog I started for creating web applications. This post goes into security for web applications.</p>
<h2>Prevent Against SQL Injection</h2>
<p>Read about <a href="http://en.wikipedia.org/wiki/SQL_injection">SQL injection</a> and learn how to prevent it for the langauge and database you are using.</p>
<h2>All User Input is Filtered</h2>
<p>Never trust user input.  This includes cookies and hidden form field values.</p>
<h2>Read the Open Web Application Security Project</h2>
<p>Read <a href="https://www.owasp.org/index.php/Category:OWASP_Guide_Project">the Open Web Application Security Project</a>.</p>
<h2>All Passwords are Hashed with a Salt</h2>
<p>Hash all passwords using a <a href="http://security.stackexchange.com/q/21263/396">salt</a> and all salts are different to prevent against <a href="http://en.wikipedia.org/wiki/Rainbow_table">rainbow attacks</a>.</p>
<p>The hashing algorithm should be bcrypt or scrypt for storing passwords.  Look into <a href="http://codahale.com/how-to-safely-store-a-password/">How To Safely Sroe a Password</a>.</p>
<p>Do <strong>not</strong> use MD5 or any SHA algorithm.  SHA algorithms are meant to be fast, which should not be used for trying to securely store passwords.</p>
<h2>Use a Standard Authentication System</h2>
<p>Do not role your own authentication system.</p>
<h2>Process Credit Card Information Correctly</h2>
<p>Look into the <a href="https://www.pcisecuritystandards.org/">PCI Security Standards</a> for financial security information.</p>
<h2>Use HTTPS for Sensitive Data</h2>
<p>Set up your <a href="http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt">SSL</a>/<a href="http://en.wikipedia.org/wiki/Https">HTTPS</a> certs correctly and check it against <a href="https://www.ssllabs.com/ssltest/">SSL Labs Server Test</a>.</p>
<h2>Prevent Session Hijacking</h2>
<p>Built in session systems are usually premade to handle these types of attacks. It is not recommended that you roll your own, but it should have the following features:</p>
<ul>
<li>Encrypted data traffic.  The session key in particular should be encrypted, but ideally all traffic should be encrypted by using SSL/TLS.</li>
<li>Long random session key.  Attackers should not be able to guess valid session keys.</li>
<li>Regenerating the session id after a successful login.  Prevents [session fixation](<a href="http://en.wikipedia.org/wiki/Session_fixation%5D">http://en.wikipedia.org/wiki/Session_fixation]</a>.</li>
<li>Change the cookie value with each and every request.  This reduces the window for an attacker to hijack the session.</li>
</ul>
<h2>Prevent Cross Site Scripting (XSS)</h2>
<p>Unfiltered query parameters that are added to the DOM are an easy way for attackers to use cross site scripting to pull data from your users.  Filter all query parameters; see <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">Cross-site Scripting</a> for more information on common attacks and prevention methods.</p>
<h2>Prevent Page Embedding</h2>
<p>You can prevent page embedding with the following header:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code>X-Frame-Options: DENY
</code></pre></div>
<p>This will cause browsers to refuse requests for framing in that page.</p>
<p>You can also prevent page embedding with JavaScript to prevent users from accessing your website in an iframe.  Look into this <a href="http://stackoverflow.com/questions/7776281/javascript-jquery-how-to-detect-if-a-page-is-embedded-by-others">StackOverflow solution</a>.</p>
<h2>Prevent Cross Site Request Forgeries</h2>
<p>Cross site request forgeries are attacks by a malicious user whereby they craft a link to a site which a user is know to have been authenticated.  For example, say your site is a bank website; the malicious user may craft a URL for you site that when a user clicks on it, deposits money into the attacker&#x27;s account.  The attacker then sends the link to users who may have been logged into your bank website.</p>
<p>According to <a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery">Wikipedia</a>:</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user&#x27;s web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action.</p>
</blockquote>
<h2>Prevent Click Jacking</h2>
<p>Similar to <a href="#prevent-page-embedding">Page Embedding</a>, click jacking works by:</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>A user might receive an email with a link to a video about a news item, but another valid page, say a product page on Amazon.com, can be &quot;hidden&quot; on top or underneath the &quot;PLAY&quot; button of the news video. The user tries to &quot;play&quot; the video but actually &quot;buys&quot; the product from Amazon.</p>
</blockquote>
<p>Other known exploits include:</p>
<ul>
<li>Tricking users into enabling their webcam and microphone through Flash</li>
<li>Tricking users into making their social networking profile information public</li>
<li>Making users follow someone on Twitter[8]</li>
<li>Sharing links on Facebook</li>
</ul>
<p>See <a href="http://en.wikipedia.org/wiki/Clickjacking">Wikipedia</a> for more information.</p>
<h2>Verify That Server Software is Up to Date</h2>
<p>Make sure that the software on your system is up to date with the latest patches.</p>
<h2>Verify That Packages, Modules, Plugins, etc are Up to Date</h2>
<p>Make sure that the latest software used by your projest is up to date with the latest patches.</p>
<h2>Verify That Your Database is Secured</h2>
<p>Make sure that connections to the database are at least password protected.  Verify that only the least amount of permissions are being used.</p>
<p>Make sure that confidential information is encrypted or hashed.</p>
<h2>Attempt to Make Your App Run As Non-Root</h2>
<p>Apply <a href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">the principle of least privilege</a> and try to have your app run as non-root as often as possible.</p>
<h2>Use the Content-Security-Policy Header</h2>
<p>Specify the following header to make the browser only run certain content depending on its origin:</p>
<p><strong>example</strong></p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code>Content-Security-Policy: script-src &#x27;self&#x27; https://apis.google.com
</code></pre></div>
<p>You can also specify the following type of content:</p>
<ul>
<li>script-src (JavaScript)</li>
<li>connect-src (XMLHttpRequest, WebSockets, and EventSource)</li>
<li>font-src (Fonts)</li>
<li>frame-src (Frame Urls)</li>
<li>img-src (Images)</li>
<li>media-src (Audio and Videos)</li>
<li>object-src (Flash)</li>
<li>style-src (CSS)</li>
</ul>
<h2>Do Not Allow Mime Sniffing with User Uploaded Content</h2>
<p>You can tell browsers to not try to guess Mime Types of files with the following header:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code>X-CONTENT-TYPE-OPTIONS: nosniff
</code></pre></div>
<p>For example, say a user uploads an HTML file. You intend to serve it to users as a text file, but the browser will attempt to serve it as an HTML page.  You can tell the browser that you know what you are doing and that the Mime Type you are providing is indeed correct by using the above header.</p>
<h2>Force HTTPS Traffic</h2>
<p>You can force HTTPS Traffic with the following header:</p>
<div class="overflow-auto rounded bg-gray-200 p-4 font-mono text-sm dark:bg-gray-800 dark:text-gray-100"><pre><code>Scrict-Transport-Security: max-age=31536000; includeSubDomains
</code></pre></div>
<p>This will force <code>https://website.com</code> even when typing in <code>http://website.com</code></p>


This post was originally on a blog I started for creating web applications. This post goes into security for web applications.

## Prevent Against SQL Injection

Read about [SQL injection](http://en.wikipedia.org/wiki/SQL_injection) and learn how to prevent it for the langauge and database you are using.

## All User Input is Filtered

Never trust user input.  This includes cookies and hidden form field values.

## Read the Open Web Application Security Project

Read [the Open Web Application Security Project](https://www.owasp.org/index.php/Category:OWASP_Guide_Project).

## All Passwords are Hashed with a Salt

Hash all passwords using a [salt](http://security.stackexchange.com/q/21263/396) and all salts are different to prevent against [rainbow attacks](http://en.wikipedia.org/wiki/Rainbow_table).

The hashing algorithm should be bcrypt or scrypt for storing passwords.  Look into [How To Safely Sroe a Password](http://codahale.com/how-to-safely-store-a-password/).

Do **not** use MD5 or any SHA algorithm.  SHA algorithms are meant to be fast, which should not be used for trying to securely store passwords.

## Use a Standard Authentication System

Do not role your own authentication system.

## Process Credit Card Information Correctly

Look into the [PCI Security Standards](https://www.pcisecuritystandards.org/) for financial security information.

## Use HTTPS for Sensitive Data

Set up your [SSL](http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt)/[HTTPS](http://en.wikipedia.org/wiki/Https) certs correctly and check it against [SSL Labs Server Test](https://www.ssllabs.com/ssltest/).

## Prevent Session Hijacking

Built in session systems are usually premade to handle these types of attacks. It is not recommended that you roll your own, but it should have the following features:

- Encrypted data traffic.  The session key in particular should be encrypted, but ideally all traffic should be encrypted by using SSL/TLS.
- Long random session key.  Attackers should not be able to guess valid session keys.
- Regenerating the session id after a successful login.  Prevents [session fixation](http://en.wikipedia.org/wiki/Session_fixation].
- Change the cookie value with each and every request.  This reduces the window for an attacker to hijack the session.

## Prevent Cross Site Scripting (XSS)

Unfiltered query parameters that are added to the DOM are an easy way for attackers to use cross site scripting to pull data from your users.  Filter all query parameters; see [Cross-site Scripting](http://en.wikipedia.org/wiki/Cross-site_scripting) for more information on common attacks and prevention methods.

## Prevent Page Embedding

You can prevent page embedding with the following header:

```
X-Frame-Options: DENY
```

This will cause browsers to refuse requests for framing in that page.

You can also prevent page embedding with JavaScript to prevent users from accessing your website in an iframe.  Look into this [StackOverflow solution](http://stackoverflow.com/questions/7776281/javascript-jquery-how-to-detect-if-a-page-is-embedded-by-others).

## Prevent Cross Site Request Forgeries

Cross site request forgeries are attacks by a malicious user whereby they craft a link to a site which a user is know to have been authenticated.  For example, say your site is a bank website; the malicious user may craft a URL for you site that when a user clicks on it, deposits money into the attacker's account.  The attacker then sends the link to users who may have been logged into your bank website.

According to [Wikipedia](http://en.wikipedia.org/wiki/Cross-site_request_forgery):

> At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user's web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action.

## Prevent Click Jacking

Similar to [Page Embedding](#prevent-page-embedding), click jacking works by:

> A user might receive an email with a link to a video about a news item, but another valid page, say a product page on Amazon.com, can be "hidden" on top or underneath the "PLAY" button of the news video. The user tries to "play" the video but actually "buys" the product from Amazon.

Other known exploits include:

- Tricking users into enabling their webcam and microphone through Flash
- Tricking users into making their social networking profile information public
- Making users follow someone on Twitter[8]
- Sharing links on Facebook

See [Wikipedia](http://en.wikipedia.org/wiki/Clickjacking) for more information.

## Verify That Server Software is Up to Date

Make sure that the software on your system is up to date with the latest patches.

## Verify That Packages, Modules, Plugins, etc are Up to Date

Make sure that the latest software used by your projest is up to date with the latest patches.

## Verify That Your Database is Secured

Make sure that connections to the database are at least password protected.  Verify that only the least amount of permissions are being used.

Make sure that confidential information is encrypted or hashed.

## Attempt to Make Your App Run As Non-Root

Apply [the principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and try to have your app run as non-root as often as possible.

## Use the Content-Security-Policy Header

Specify the following header to make the browser only run certain content depending on its origin:

**example**

```
Content-Security-Policy: script-src 'self' https://apis.google.com
```

You can also specify the following type of content:

- script-src (JavaScript)
- connect-src (XMLHttpRequest, WebSockets, and EventSource)
- font-src (Fonts)
- frame-src (Frame Urls)
- img-src (Images)
- media-src (Audio and Videos)
- object-src (Flash)
- style-src (CSS)

## Do Not Allow Mime Sniffing with User Uploaded Content

You can tell browsers to not try to guess Mime Types of files with the following header:

```
X-CONTENT-TYPE-OPTIONS: nosniff
```

For example, say a user uploads an HTML file. You intend to serve it to users as a text file, but the browser will attempt to serve it as an HTML page.  You can tell the browser that you know what you are doing and that the Mime Type you are providing is indeed correct by using the above header.

## Force HTTPS Traffic

You can force HTTPS Traffic with the following header:

```
Scrict-Transport-Security: max-age=31536000; includeSubDomains
```

This will force `https://website.com` even when typing in `http://website.com`
