Menu
Forums
All threads
Latest threads
New posts
Trending threads
New posts
Search forums
Trending
What's new
New posts
New profile posts
Latest activity
Members
Current visitors
New profile posts
Search profile posts
Upgrades
Log in
Register
What's new
Search
Search
Search titles only
By:
All threads
Latest threads
New posts
Trending threads
New posts
Search forums
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
Software Development
Programming
Tutorials
A couple of language-agnostic tips for web app security
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Adil" data-source="post: 270796" data-attributes="member: 3031"><p><strong>Preamble</strong></p><p>This little tutorial/reference serves as a reminder/checklist for securing your web apps. However, it is not the only guide out there and nor is it the only guide you should refer to. Rather, it should be one of many.</p><p></p><p><strong>The list</strong></p><p><u>Error Handling</u></p><p>This is a pretty obvious one. In most web frameworks (Play!, Rails, webapp2, etc), any errors are output using a http code and some text. </p><p>Let's take this scenario:</p><p>You have a blogging platform, and you've just rolled out a new feature. However, you have not catered for extreme edge cases. As a result, the blogging engine cannot save some data to a database.</p><p>[CODE]</p><p>// this is dummy code</p><p>var userId = request.get('user_id');</p><p>db.saveData('users', 'user_id', userId, function(err) {});</p><p>[/CODE]</p><p>Here we see that some data (in this case, 'user_id') is being saved to the database. If there is an error in handling it, good practice suggests:</p><p>[CODE]</p><p>var errCode = 500;</p><p>response.write(utils.errFor(errCode));</p><p>[/CODE]</p><p>That would give you a 500 error. This is vital. If you were to give the end user a stacktrace (that's not encrypted - Google encrypt Youtube errors), you'd be exposing yourself to a potential hacker gaining access to your system. This is the first point you must address.</p><p></p><p><u>Using HTTPS</u></p><p>This is pretty self explanatory. HTTPS adds a layer of security to your site, so attackers cannot perform man in the middle attacks (see wikipedia for more info). HTTPS should be enforced throughout the site, but especially on any areas handling sensitive data - this includes, but is not limited to:</p><ul> <li data-xf-list-type="ul">Billing areas</li> <li data-xf-list-type="ul">User sign in/registration/account management</li> </ul><p><u>Extensive Logging</u></p><p>Logging is pretty much vital in any large application. Logging will allow you to inspect site stats - loading times, error codes, etc. Logging will also allow you to keep track of any suspicious activity. Many languages have a large collection of logging frameworks. Most web servers also log data.</p><p></p><p><u>Proper authentication handling</u></p><p>This is my last point. When a user is faced with a login screen and tries to login, they may be greeted with an error. Now, this is bad practice.</p><p>Why?</p><p>Well, if a hacker becomes aware of a user's email address, they may also have a vague idea of their password. So, when the hacker visits the login page, he/she will try to login and will be greeted with 'password incorrect'. This means the hackers now knows that the password they supplied is incorrect. Their job becomes a bit easier.</p><p>Example scenario:</p><p>User a</p><p>Hacker b</p><p>Password list: apples, oranges, pears, bananas, grapes, cucumber <(this is the password)</p><p>We have 6 potential passwords.</p><p></p><p>B gets a's email (<a href="mailto:a@test.com">a@test.com</a>). B then goes to the login of site C. B tries to login with the password "apples". B does not succeed, but B now knows he/she has eliminated one password. From having a 1/6 chance of getting the password, they now have a 20% chance. They continue until they breach the system.</p><p></p><p>So, to conclude, here is a basic overview of the points I have just discussed.</p><ul> <li data-xf-list-type="ul">Do not send stack traces or any sort of specific error to the user (only send errors to trusted users - in a development or staging environment).</li> <li data-xf-list-type="ul">Using SSL across your site</li> <li data-xf-list-type="ul">Logging everything (Loggly and Logentries are two good log analysis tools)</li> <li data-xf-list-type="ul">Redirecting the user to the login page rather than sending an error to them.</li> </ul><p>I hope you learnt something new!</p><p>~Adil</p></blockquote><p></p>
[QUOTE="Adil, post: 270796, member: 3031"] [B]Preamble[/B] This little tutorial/reference serves as a reminder/checklist for securing your web apps. However, it is not the only guide out there and nor is it the only guide you should refer to. Rather, it should be one of many. [B]The list[/B] [U]Error Handling[/U] This is a pretty obvious one. In most web frameworks (Play!, Rails, webapp2, etc), any errors are output using a http code and some text. Let's take this scenario: You have a blogging platform, and you've just rolled out a new feature. However, you have not catered for extreme edge cases. As a result, the blogging engine cannot save some data to a database. [CODE] // this is dummy code var userId = request.get('user_id'); db.saveData('users', 'user_id', userId, function(err) {}); [/CODE] Here we see that some data (in this case, 'user_id') is being saved to the database. If there is an error in handling it, good practice suggests: [CODE] var errCode = 500; response.write(utils.errFor(errCode)); [/CODE] That would give you a 500 error. This is vital. If you were to give the end user a stacktrace (that's not encrypted - Google encrypt Youtube errors), you'd be exposing yourself to a potential hacker gaining access to your system. This is the first point you must address. [U]Using HTTPS[/U] This is pretty self explanatory. HTTPS adds a layer of security to your site, so attackers cannot perform man in the middle attacks (see wikipedia for more info). HTTPS should be enforced throughout the site, but especially on any areas handling sensitive data - this includes, but is not limited to: [LIST] [*]Billing areas [*]User sign in/registration/account management [/LIST] [U]Extensive Logging[/U] Logging is pretty much vital in any large application. Logging will allow you to inspect site stats - loading times, error codes, etc. Logging will also allow you to keep track of any suspicious activity. Many languages have a large collection of logging frameworks. Most web servers also log data. [U]Proper authentication handling[/U] This is my last point. When a user is faced with a login screen and tries to login, they may be greeted with an error. Now, this is bad practice. Why? Well, if a hacker becomes aware of a user's email address, they may also have a vague idea of their password. So, when the hacker visits the login page, he/she will try to login and will be greeted with 'password incorrect'. This means the hackers now knows that the password they supplied is incorrect. Their job becomes a bit easier. Example scenario: User a Hacker b Password list: apples, oranges, pears, bananas, grapes, cucumber <(this is the password) We have 6 potential passwords. B gets a's email ([email]a@test.com[/email]). B then goes to the login of site C. B tries to login with the password "apples". B does not succeed, but B now knows he/she has eliminated one password. From having a 1/6 chance of getting the password, they now have a 20% chance. They continue until they breach the system. So, to conclude, here is a basic overview of the points I have just discussed. [LIST] [*]Do not send stack traces or any sort of specific error to the user (only send errors to trusted users - in a development or staging environment). [*]Using SSL across your site [*]Logging everything (Loggly and Logentries are two good log analysis tools) [*]Redirecting the user to the login page rather than sending an error to them. [/LIST] I hope you learnt something new! ~Adil [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
Software Development
Programming
Tutorials
A couple of language-agnostic tips for web app security
Top