51
mvandam
Re: Default Notification Method
  • 2003/12/12 18:20

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


quote]
Does posting a message in the Feature Request forum is the official way to suggest a modification?
[/quote]
This seems to be what most people do... but I would suggest posting on sourceforge feature request (bottom right block on homepage) to make sure it doesn't get forgotten. Thanks!



52
mvandam
Re: security bug from www.cnns.net
  • 2003/12/11 17:44

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Thank you. I can't read most of it, but I believe this is the same vulnerability posted at another security site and all the issues have been fixed in 2.0.5.1.



53
mvandam
Re: Session Bug Patch
  • 2003/12/11 1:03

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


I think you can just do the following:

Quote:

global $xoopsConfig;
$expiretime = $xoopsConfig['session_expire'] * 60;


This will give you the configured session lifetime, converted to seconds.



54
mvandam
Re: Security Focus shows Xoops flaws - is 1.3.10 safe?
  • 2003/12/11 0:57

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


I'll just make a quick comment here as there is tons of info on the net about it, and another thread recently touched on some of this:

https://xoops.org/modules/newbb/viewto ... hp?topic_id=14580&forum=4

In general, the vulnerabilities posted about web scripts include problems like SQL injection vulnerabilities, or 'cross-site scripting' (XSS) vulnerabilities.

The simple solution to SQL injection is make sure you NEVER use $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_COOKIE_VARS in your queries. These variables are classified as UNTRUSTED data because they are coming from an outside source. ALWAYS wrap untrusted data inside $xoopsDB->quoteString() to make it safe to use inside queries.

The simple solution to XSS vulnerabilities is to always pass untrusted data through the function htmlspecialchars before displaying it on the page. This will prevent any malicous HTML or javascript from affecting other users.

I'm sure I'm oversimplifying a lot and I am by no means an expert in this area, but these two steps account for the vast majority of problems. You might want to read up a little on these kinds of attacks in general... i.e. how they are done, why they are dangerous, and how to prevent them.

Hope this helps



55
mvandam
Re: foreach $HTTP_GET_VARS
  • 2003/12/10 1:14

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


I have to agree with Dave_L on this one. I think those lines were added to XOOPS code in a hurry at some point to fix complaints about not working with register_globals off.

It is true if you use the "loop" method, if you forget to initialize a variable in the module, then you can potentially be open to a variety of attacks depending on how that variable is used. i.e. The attacker can feed a value into that variable by adding an argument to the URL.

As a *preferred* method, I would choose Dave_L's approach, or simply use the full $HTTP_POST_VARS['var1'] in the places where you actually need it.

So far this really doesn't relate specifically to SQL injection. The idea of doing 'addslashes' on all non-strings is not good as it leads to unpredictable state of your variables. i.e. You should only 'addslashes' if you really need to, and only the rest of your module code will really know this. A loop at the beginning of your code doesn't know this. Also, 'addslashes' is not really a good way to make things database-safe -- it works for MySQL but not for many other databases which may be supported in the future.

The way to avoid SQL injection is to not use HTTP_POST_VARS or HTTP_GET_VARS etc. **directly** in SQL statements.

Use quoteString:

$xoopsDB->query('SELECT * FROM sometable WHERE user=' . $xoopsDB->quoteString($HTTP_GET_VARS['username']));

but DO NOT use:

$xoopsDB->query('SELECT * FROM sometable WHERE user=' . $HTTP_GET_VARS['username']);

Anyways, there are other issues related to HTTP_VARS and SQL injection is just one of them. The other big thing to worry about is if you directly echo an $HTTP_VAR to the page you are creating. If someone put malicious HTML or javascript into that value, then that malicous code appears on your webpages where it could do anything from disrupting the page layout to stealing a user's cookies (which can allow password stealing and session hijacking). I only know a little about this stuff but the 'net has a huge amount of info if you're interested.

EDIT: by the way, the usual fix for making things display-safe is to use htmlspecialchars($HTTP_GET_VARS['somevar']), but depending exactly what the variable is used for this may or may not work.



56
mvandam
Re: Site Name and Slogon won't save
  • 2003/12/6 23:32

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


If you are using Fantastico/CPanel for install, search the forums (for 'fantastico' and/or 'slogan'). With Fantastico your problem is known to have happened with at least a few users...



57
mvandam
Re: Removing the intermediate flash screen
  • 2003/12/6 5:00

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


I think the messages should *always* be there. Maybe the admin/user could choose *how* they are shown but I don't they should be allowed to be removed. You never know when an unexpected error is going to crop up and you need to try reposting, etc...

As for how it is shown, I guess the options are like the current intermediate page in xoops, or just showing the message on the target page (e.g. sourceforge does this after posting a bug/message). The latter is easily done with cookies as described above, or maybe better, with session variables. The problem is that it is generally not a very good idea to generate output after a POST request, so you still need a redirect, but it can be an immediate one with no intermediate page. The message is shown once you get to the final page.



58
mvandam
Re: Sponteneous new_bb crash; please comment
  • 2003/12/5 23:08

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


This may be similar to the problem David_Topping had (mentioned in that other thread). It was related to some inconsistencies that arose among the forum tables. Not sure why this happens... I think it is a php or MySQL problem because I have a similar thing happen on one occasion with a different PHP script (not xoops).

Anyways, I've forwarded you some email transcript of the process which eventually led to solving the problem. (To the email address in your user profile.)

Good luck!



59
mvandam
Re: Database problem
  • 2003/12/5 20:32

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


If you're positive it is a *connection* problem, you can check the settings manually in mainfile.php and make sure everything was set up properly for your server.



60
mvandam
Re: How do I do this without hacking the core?
  • 2003/12/3 21:42

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Quote:

If the developers would add something in the header.php file such as:

include "extra.php";

...we can have extra flexibility to add template variables to the the theme without mucking with the original file

Something like this is probably a good idea for themes which include stuff that is normally part of a block etc. Though instead of "extra.php" a better name might be "theme_init.php" or something, where this file would be located in the directory of the particular theme you are using.




TopTop
« 1 ... 3 4 5 (6) 7 8 9 ... 21 »



Login

Who's Online

61 user(s) are online (39 user(s) are browsing Support Forums)


Members: 0


Guests: 61


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Oct 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits