Should we also review where queryf is used in key modules, as this is often misused by developers who want a quick way to access core tables.
Herko
and what about mysql5 too?
but in particular mysql5 has some functions that could be utilised (if used correctly, and that input is validated and sanitized before hand)
especially as mysql5 is able to use multiple queries in 1 session whereas mysql4 can only accept single queries at 1 time.. it could speed things up if multiple query ability is introduced.
I see someone has worked on adding mysqli support too, so even with mysqli, multiple queries can be utilised by the function mysqli_multi_query() instead of mysqli_query().
certainly something to look at tho either way.
nice reading, very exhausting tho..
thanks for those dave & dave.
with regards to the conversation I had with Dave last night, it is apparent that the exit(); after redirect_header() is not required as redirect_header function is already terminated with exit(); in the function itself. I'll remove the extra exit(); in a bit for consistency.
my next task that I will look for is in the mysql query statements. In particular making sure that all values in the sql query itself are quoted '' regardless of datatype, this includes alphanumeric values aswell as integer values. this will help decrease SQLi attacks.
for example >
It's an interesting idea - it still doesn't stop local communities having a support site - but it does possibly remove the issues of their having to pay hosting etc.
I still say we should also have no objections if someone who operates a xoops site wants to support ICMS also... or if someone wants to run their site on their own server - but it would be nice to offer the option
james, looks great so far from the "view into source output". What I would add is a [html]label for the input(s).
after a quick look I ran into problems when the id of the single centercolums were assigned.
eg, I never get a "single-top-center-column" though both left and right centerblocks were not set. This is because the values are overwritten some lines below.
it is true that when both centerleft and centerright were empty normally this should be rendered as "single-top-center-column".
but, ... some lines below there is
<{elseif empty($xoops_clblocks) && !empty($xoops_ccblocks)}>
which is in this explecit situaton also true so the id of the centerblock will be rendered as "wide-top-right-column" only.
We can solve this situation copying the first block of lines (of the 3 blocks where the ids were assigned, not the blockoutput) below the 2 others (ctop centerblocks related)
So we get this instead:
<{if empty($xoops_ccblocks) && empty($xoops_crblocks)}>
<{assign var='tclc' value='single-top-left-column'}>
<{elseif empty($xoops_ccblocks) && !empty($xoops_crblocks)}>
<{assign var='tclc' value='wide-top-left-column'}>
<{assign var='tcrc' value='wide-top-right-column'}>
<{elseif !empty($xoops_ccblocks) && empty($xoops_crblocks)}>
<{assign var='tclc' value='wide-top-left-column'}>
<{assign var='tccc' value='wide-top-center-column'}>
<{else}>
<{assign var='tclc' value='top-left-column'}>
<{/if}>
<{if empty($xoops_clblocks) && empty($xoops_ccblocks)}>
<{assign var='tcrc' value='single-top-right-column'}>
<{elseif empty($xoops_clblocks) && !empty($xoops_ccblocks)}>
<{assign var='tcrc' value='wide-top-right-column'}>
<{assign var='tccc' value='wide-top-center-column'}>
<{elseif !empty($xoops_clblocks) && empty($xoops_ccblocks)}>
<{assign var='tcrc' value='wide-top-right-column'}>
<{assign var='tclc' value='wide-top-left-column'}>
<{else}>
<{assign var='tcrc' value='top-right-column'}>
<{/if}>
<{if empty($xoops_clblocks) && empty($xoops_crblocks)}>
<{assign var='tccc' value='single-top-center-column'}>
<{elseif empty($xoops_clblocks) && !empty($xoops_crblocks)}>
<{assign var='tccc' value='wide-top-center-column'}>
<{assign var='tcrc' value='wide-top-right-column'}>
<{elseif !empty($xoops_clblocks) && empty($xoops_crblocks)}>
<{assign var='tccc' value='wide-top-center-column'}>
<{assign var='tclc' value='wide-top-left-column'}>
<{else}>
<{assign var='tccc' value='top-center-column'}>
<{/if}>
this works for me in this situation. Same counts for the bottom centerblocks.
Or is it only me stupid?
what i would like to see in the source were hr's to devide the sections more clearly. we may hide them or make the "not visible" but we may (a)buse them to clear (repair) some "module templates output errors" using clear:something.
this for now!
keep on good work my friend
michael
Slightly off topic: I spoke with a module developer the other day, who is working on a language file generation module - which could be very useful for translators
How to deal with support sites?
I'm asking all these questions because Impress gives us the opportunity to start anew, and to organise things differently without any legacy.
I was thinking. Wouldn't it be a good thing to concentrate all support activities in one place? If there would be one server where all localised support sites would be located, accessible thru a national domain and a subdomain of the main url (for instance: impresscms.nl and nl.impresscms.org)?
Why, you ask?
Well, not to control who gets to be Official and who doesn't.
Concentrating the support, and bringing it as close as possible to the main project, provides several advantages:
- the central organization can provide quality services (such as an up to date and secure codebase for all sites, free hosting),
- communication lines are short: it is easier to relay news to the support sites (and to organize the communications)
- availability and consistancy of the releases: everyone has the same releases, changes to codes are made centrally
- easier to collaborate and to share ideas, not just limited to a single support group but for the whole project
- continuity of local support: no competition between support sites
What do you think?
Herko
SVN has a big learning curve, while editing translations (language files) doesn't require one to be a developer with SVN skills. So I'm not sure if this is a good idea.
How to deal with translations is a more general issue. I'd prefer it if the language packs are provided separately, as it decreases the upload time for the files, and normally only one language is used anyway (multilang sites excluded of course, but there isn't a rock solid solution for that yet).
Also, I would prefer if a translation is checked by at least 2 people. This to improve the quality of the translation.
What are the guidelines for translations? how formal is the language, or how technical? I would love to go through the core language files to see if we can make it more user friendly, and create some language guidelines for translators.
Herko
I think that it could be posible to have all the language packs in sourceforge...
Few utilities I've found:
http://developer.spikesource.com/projects/phpsecaudit/
http://www.dragoslungu.com/2007/10/30/pixy-is-a-free-php-code-audit-tool/
http://www.php-mag.net/magphpde/magphpde_news/psecom,id,27497,nodeid,5.html
http://www.darknet.org.uk/2007/11/skavenger-source-code-auditing-tool/
As promised. here are my notes:
Notes from SPI Dynamics workshop, Richmond, VA, 2007-04-17
This free workshop was obviously intended to encourage people to buy SPI Dynamics' web security products. But the presenter, Brett Sagenich (brett.sagenich AT spidynamics DOT com), was a security engineer, not a salesman, and he provided much information of general use. His point was that web applications present numerous potential security vulnerabilities. He demonstrated actual techniques used by attackers. The reason that he discussed these details is that while they can all be addressed by proper software design, this is very labor-intensive, while SPI Dynamics' tools perform automated detection for these vulnerabilities.
Specific vulnerabilities discussed:
1. Extraneous files such as readme's, documentation, old files
- Provides info to attackers
- Old versions of scripts may have unpatched security issues.
2. Unvalidated user input
3. Visible error messages
- May reveal information useful to attackers
- Software in use
- File system paths
- Variation in error messages in response to an attacker's input can guide him.
4. SQL injection
- iterative (trial and error)
- with error messages
- blind (based on displayed output or presence/absence of output)
5. Session hijacking
- Exploit spoofable session ID, customer ID, etc.
6. XSS (or CSS, cross-site scripting)
---
I can elaborate on some of these items, if there are questions. I know that "Unvalidated user input" is a problem often encountered with XOOPS.
---
By the way, here's a good reference I found on this topic: Open Web Application Security Project (OWASP)
Hi all,
may I, the German language files (ISO) in SF.net?
gets my vote.
simplicity at it's best :)
yes dave :) but i used telnet as just 1 example.
thanks for the offer of your notes, any information that can help improve security is a bonus.
I've got most of the logic, XHTML and CSS done. There is some work needed on fine-tuning the margins and padding, but the hardest part is done.
At this point, the images need sliced, the CSS needs color matched, and the aforementioned fine-tuning needs done.
I won't be around today and much of tomorrow. If somebody else wants to take what I've done so far and continue on it, that would be a great help!!!
Work so far attached.
Let's make this first theme a team effort!!!
This is important to the longevity of ImpressCMS (or any project). I agree with Herko about what we need to be focusing on at this stage - a list of tasks that need to be completed and a clear overall vision, much like we did here when pulling together at Xi.
Why not split it up?
I mean this:
the codes that build on just the current xoops 2.0.x code will have its php4 compatbility, but
the *real* impress codes (the ones that will take it away from xoops) will be php5 native.
This is what Skalpa wanted to do with XOOPS anyway: work towards a php5 native codebase. Basically, you'd have till 8.8.08 to create a superduper new php5 only system that will make the current patching xoops work obsolete.
Herko
PS: I hope no one takes offense with these ideas - they're not in concrete, but are just raised to discuss ideas.