The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
Create Secure Mods
In this post we'll go over some basic modification vulnerabilities and how to prevent them. Preparing Data Whenever you accept input from a user, you must understand that you have no control over what is entered, period. The short version is that anything client-side can be manipulated. Even if you use Javascript or HTML limitations, they can all easily be avoided. This input includes but is not limited to:
Use the vBulletin Input Cleaner! I'm going to assume you know how to use it, even though sometimes you choose not to use it. If not, dig up a tutorial on it. A common example is fetching a row from a table using an ID in the query string. I often see this: PHP Code:
Here is what you should use... PHP Code:
PHP Code:
HTML Code:
<select name="meal"> <option value="1">Breakfast</option> <option value="2">Lunch</option> <option value="3">Dinner</option> </select> PHP Code:
PHP Code:
Point: ensure the data you expect is what you expect. If it's not, do not let them continue. False data can do a number of things of varying damage:
What is SQL injection? It's when your script does not properly clean user input, and they can actually manipulate the query using the input value. Example, A script to update a user's email address. Here is the query: Code:
UPDATE user SET email = '$value' WHERE userid = 1; Code:
my@email.com', username = 'HAHA', password = ''# Code:
UPDATE user SET email = 'my@email.com', username = 'HAHA', password = ''#' WHERE userid = 1; Code:
UPDATE user SET email = 'my@email.com', username = 'HAHA', password = '';
Preventing Injection It is very easy to prevent injection. Generally, users either input text (string) or a number (int/float). For the latter, they should already be safe assuming you used the input cleaner as suggested. For strings, however, you must use the $db->escape_string() function. What does this do? In a standard MySQL setup, it's just a wrapper for mysql_real_escape_string which in simpliest terms, prepends a backslash to any characters which may alter query. Remember to use $db->escape_string() instead of the actual function, because not every board runs MySQL! Automation I highly recommend using a function to generate queries. This is how the datamanager works, and also many of my own private hacks. How does this make it more secure? - by not relying on the coder to escape it. If you do so, you can wrap each value in the $db->sql_prepare() function, which makes it SQL safe. Here is what the function does to...
XSS (Cross Site Scripting) Cross site scripting is when a user injects HTML into any text that he posts, and in that HTML uses Javascript to communicate with his own server. What can this do? He can steal your cookie information and take over your online identity. Imagine someone doing this to an administrative account. Uh oh! Like SQL injection, XSS is actually very easy to prevent. You have two options: 1) Use TYPE_NOHTML instead of TYPE_STR when accepting string input.This has a few (minor) downsides. If you want to allow searching, or for any other reason want to retain the exact information the user enters. The alternative, is 2) Clean it using htmlspecialchars_uni() when displaying the text. This is where it gets tricky. If you display it all over the place, it can be difficult to remember to clean it every time. So what does this do exactly? Any HTML characters, such as "<", ">", and "&" are parsed as HTML, so if you convert them to their entity form ("<", ">", "&", the browser knows to display that character, and not parse it as HTML. Now it is impossible for any hackers to inject HTML into your site. Summary
You may not copy this article without my permission. |
#22
|
||||
|
||||
It's just good coding practice to do so. Say for instance you have a moderator or someone whom you allow access to the admin CP (a business partner for instance) and you have a falling out - he/she then injects something nasty theough the AdminCP and BOOM!
Sir Adrian, ok, i'm learning this, thanks. So after escaping it, if I want to display it in a <textarea> type input box for user to edit it, it's showing as follows: Quote:
Quote:
|
#23
|
||||
|
||||
Why are you displaying it after escaping it? It goes into the query escaped, and when you read from the DB again it should be OK.
|
#24
|
||||
|
||||
It goes into query escaped before being put into database. Then if user wants to edit the text, it's displayed again, within the <textarea> box for them to modify.
I'd be fine if the initial cleaning of the data totally stripped out all the /n/r/n/r stuff as well since i have no need for them to post data on new lines. Am i missing something or do i need to create a regex before passing data to the update or save query? |
#25
|
||||
|
||||
Only escape just before using it in a query. That's all it is for. You should never display it after it has been escaped; that doesn't make sense!
|
#26
|
||||
|
||||
Thanks for your help on this issue SirAdrian.
So you're telling me that somewhere I am escaping it before displaying it in the <textarea> box? |
#27
|
||||
|
||||
Yeah you must be. Post your code here (or make a new thread in programming / coders discussion and I will take a look).
|
#28
|
||||
|
||||
ok will post it in programming discussions - thanks
|
#29
|
||||
|
||||
Excellent article SirAdrian, was a great read.
|
#30
|
|||
|
|||
Definitely. Thank you for taking the time to write this article, Adrian. :up:
|
#31
|
|||
|
|||
Nice article, thanks for taking the time to write this out.
|
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|