| Data injection problems [message #169558] |
Fri, 17 September 2010 20:14  |
Stephan Bird
Messages: 4
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
Hi all
I have been maintaining a website for my parents' business for a while
now, and as part of this have written a form to try and generate
enquiries. This was working fine up until a few days ago, but now seems to
be hijacked with spurious code when I try and validate it at
validator.w3.org . I can't see the extra code when I visit the site in
e.g. Firefox, though it is visible when I go to the page in lynx.
The page in question is http://www.cwmcadnantvalley.co.uk/bookenq.php ,
and the source of the page is at the same domain, page bookenq.php.txt
Could this be something wrong with the w3 validator, or perhaps things at
my end?
Many thanks
Stephan
|
|
|
|
| Re: Data injection problems [message #169559 is a reply to message #169558] |
Fri, 17 September 2010 20:45  |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Stephan Bird)
> I have been maintaining a website for my parents' business for a while
> now, and as part of this have written a form to try and generate
> enquiries. This was working fine up until a few days ago, but now seems to
> be hijacked with spurious code when I try and validate it at
> validator.w3.org . I can't see the extra code when I visit the site in
> e.g. Firefox, though it is visible when I go to the page in lynx.
>
> The page in question is http://www.cwmcadnantvalley.co.uk/bookenq.php ,
> and the source of the page is at the same domain, page bookenq.php.txt
>
> Could this be something wrong with the w3 validator, or perhaps things at
> my end?
Are you validating the PHP source? This can't work. You have to validate
the output of the script, i.e. the result in the browser. And I get a
green there.
Micha
|
|
|
|
| Re: Data injection problems [message #169562 is a reply to message #169559] |
Fri, 17 September 2010 21:17 |
Stephan Bird
Messages: 4
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
On Fri, 17 Sep 2010 22:45:32 +0200 in
0qk796lhmstmm6nppua5c13ofnaovrjvpu(at)mfesser(dot)de, Michael Fesser wrote:
> .oO(Stephan Bird)
>
>> Could this be something wrong with the w3 validator, or perhaps things
>> at my end?
>
> Are you validating the PHP source? This can't work. You have to validate
> the output of the script, i.e. the result in the browser. And I get a
> green there.
>
> Micha
I am not trying to validate the source per se (the txt file), just posted
it to show what the script actually was that made the .php file.
As to validation of the php file what happens when you try and validate it
again? I am now getting a red directly from http://validator.w3.org/ ,
although Chris Prederick's toolbar gives a green.
Stephan
|
|
|
|
| Re: Data injection problems [message #169563 is a reply to message #169558] |
Fri, 17 September 2010 21:32 |
Beauregard T. Shagnas
Messages: 154
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Stephan Bird wrote:
> Could this be something wrong with the w3 validator, or perhaps things
> at my end?
At the W3 validator, check the 'show source' checkbox. Then look at line
130. Lots of ED medication links.
Change your FTP password immediately, then re-upload the page to your
server.
--
-bts
-Four wheels carry the body; two wheels move the soul
|
|
|
|
|
|
| Re: Data injection problems [message #169565 is a reply to message #169558] |
Fri, 17 September 2010 21:59 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/17/2010 4:14 PM, Stephan Bird wrote:
> Hi all
>
> I have been maintaining a website for my parents' business for a while
> now, and as part of this have written a form to try and generate
> enquiries. This was working fine up until a few days ago, but now seems to
> be hijacked with spurious code when I try and validate it at
> validator.w3.org . I can't see the extra code when I visit the site in
> e.g. Firefox, though it is visible when I go to the page in lynx.
>
> The page in question is http://www.cwmcadnantvalley.co.uk/bookenq.php ,
> and the source of the page is at the same domain, page bookenq.php.txt
>
> Could this be something wrong with the w3 validator, or perhaps things at
> my end?
>
> Many thanks
>
> Stephan
No, look at the page source in your browser. Your site has been hacked.
As Beauregard said, change your ftp password immediately, and upload
your whole site from a clean backup.
And notify your host, just in case it was them who got hacked, instead
of just your account.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Data injection problems [message #169575 is a reply to message #169564] |
Sat, 18 September 2010 09:28 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Beauregard T. Shagnasty)
> Michael Fesser wrote:
>
>> ... You have to validate the output of the script, i.e. the result in
>> the browser. And I get a green there.
>
> At the W3C validator?
Yes, but now I see what I did differently and also the malicious code.
> No green I see.
>
> Errors found while checking this document as HTML 4.01 Strict!
> Result: 547 Errors, 14 warning(s)
>
> < http://validator.w3.org/check?uri=http%3A%2F%2Fwww.cwmcadnantvalley.co.uk%2 Fbookenq.php&charset=%28detect+automatically%29&doctype=Inline& ss=1&group=0&verbose=1&user-agent=W3C_Validator%2F1.1>
Indeed. What I did was to open the page in my Opera and use its built-in
feature to send the source of the current page to the W3 validator. And
there I got a green. So obviously my Opera got another code than the W3
validator.
> See the source from line 130 on, and note the positioning to waaay off
> page. (I don't know how that code gets there.)
Same here. I don't have the time right now to investigate a bit further,
but I see at least some problems in the PHP code. At the end there are
includes which include files via HTTP, even if they're on the same
server. While this not only causes a lot of overhead, it could also be
possible that somewhere else in the code there might be a code injection
vulnerability. Or the server was compromised and automatically adds this
code, unless it recognizes some know user agents. As said - in my Opera
the code is clean.
Micha
|
|
|
|
| Re: Data injection problems [message #169576 is a reply to message #169575] |
Sat, 18 September 2010 09:32 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Michael Fesser)
> Same here. I don't have the time right now to investigate a bit further,
> but I see at least some problems in the PHP code. At the end there are
> includes which include files via HTTP, even if they're on the same
> server. While this not only causes a lot of overhead, it could also be
> possible that somewhere else in the code there might be a code injection
> vulnerability. Or the server was compromised and automatically adds this
> code, unless it recognizes some know user agents. As said - in my Opera
> the code is clean.
Short addition: Opera and Firefox show clean code, Lynx gets the spam.
And BTW the page is also vulnerable to cross-site scripting because of
things like this:
[…] value="<?php echo $_REQUEST['backpack'] ?> […]
Micha
|
|
|
|
| Re: Data injection problems [message #169577 is a reply to message #169576] |
Sat, 18 September 2010 11:00 |
Beauregard T. Shagnas
Messages: 154
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Michael Fesser wrote:
> Short addition: Opera and Firefox show clean code, Lynx gets the spam.
Probably because Lynx (text-only browser) doesn't utilize the CSS and
the positioning stuck in the hacker's addition.
Remember that "line 130?"
<div style='position:absolute;top:-95832;left:-948289;'>
It places all those viagra links 95-thousand pixels above the top of,
and nearly a million pixels to the left of, your graphical browsers'
viewports.
I'm not sure why the hacker/spammer doesn't want visitors to see them.
Surely, nobody is going to click on them. Maybe the h/s is just wanting
the googlebot to find them. <shrug>
--
-bts
-Four wheels carry the body; two wheels move the soul
|
|
|
|
| Re: Data injection problems [message #169579 is a reply to message #169577] |
Sat, 18 September 2010 11:23 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 18-09-10 13:00, Beauregard T. Shagnasty wrote:
> Michael Fesser wrote:
>
>> Short addition: Opera and Firefox show clean code, Lynx gets the spam.
>
> Probably because Lynx (text-only browser) doesn't utilize the CSS and
> the positioning stuck in the hacker's addition.
>
> Remember that "line 130?"
>
> <div style='position:absolute;top:-95832;left:-948289;'>
>
> It places all those viagra links 95-thousand pixels above the top of,
> and nearly a million pixels to the left of, your graphical browsers'
> viewports.
>
> I'm not sure why the hacker/spammer doesn't want visitors to see them.
> Surely, nobody is going to click on them. Maybe the h/s is just wanting
> the googlebot to find them.<shrug>
>
Its only making his page load 3 times slower,
because the page is about 3 times bigger.....
I think modern browser stop parsing after '</html>' ?
but i'm not sure...
(and that would be offtopic here, in case JS read this ;-)
--
Luuk
|
|
|
|
| Re: Data injection problems [message #169581 is a reply to message #169579] |
Sat, 18 September 2010 11:41 |
Beauregard T. Shagnas
Messages: 154
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Luuk wrote:
> I think modern browser stop parsing after '</html>' ?
> but i'm not sure...
No, modern browsers attempt error correction, so would continue to
process whatever came later. I've seen pages with several
<html><body>..</body></html> sections and they do display. But possibly
not as the author intended...
--
-bts
-Four wheels carry the body; two wheels move the soul
|
|
|
|
| Re: Data injection problems [message #169582 is a reply to message #169577] |
Sat, 18 September 2010 12:01 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 18/09/10 12:00, Beauregard T. Shagnasty wrote:
> Michael Fesser wrote:
>
>> Short addition: Opera and Firefox show clean code, Lynx gets the spam.
>
> Probably because Lynx (text-only browser) doesn't utilize the CSS and
> the positioning stuck in the hacker's addition.
>
> Remember that "line 130?"
>
> <div style='position:absolute;top:-95832;left:-948289;'>
>
> It places all those viagra links 95-thousand pixels above the top of,
> and nearly a million pixels to the left of, your graphical browsers'
> viewports.
>
> I'm not sure why the hacker/spammer doesn't want visitors to see them.
> Surely, nobody is going to click on them. Maybe the h/s is just wanting
> the googlebot to find them. <shrug>
Ah, that would explain why the source concerned isn't served to known
browsers.
I requested the page with:
wget - had the links
amaya - had the links
ff 3.6, seamonkey, chrome, opera, epiphany, konqueror - no links
ie under wine - I can't view source (need to look at that) so I don't
know if it was delivered or not.
op reported that it appeared in lynx
Perhaps the server config has been hacked to tack the code onto pages
for search agents?
I couldn't see anything like an include in the original php at the point
that the hack appears, it's after the closing "</html>" and the op's
code doesn't put anything there, so I suspect a higher level hack in the
server.
Hack the server to deliver the links, but in such a way that they don't
appear except to spiders?
So they bump up the ratings for the website whenever anyone does a
google etc search for the meds concerned?
So basically it's a hack by the fake pharmaceuticals people to bump
their websites higher up the search engines, and not actually intended
to be seen by people browsing the websites (because once it's been
noticed, it's likely to get looked at and removed).
Rgds
Denis McMahon
|
|
|
|
|
|
| Re: Data injection problems [message #169586 is a reply to message #169576] |
Sat, 18 September 2010 14:26 |
Stephan Bird
Messages: 4
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
On Sat, 18 Sep 2010 11:32:24 +0200 in
1l199652q821h5celav9s6sv2sjbl2v943(at)mfesser(dot)de, Michael Fesser wrote:
> .oO(Michael Fesser)
>
>> Same here. I don't have the time right now to investigate a bit further,
>> but I see at least some problems in the PHP code. At the end there are
>> includes which include files via HTTP, even if they're on the same
>> server. While this not only causes a lot of overhead, it could also be
>> possible that somewhere else in the code there might be a code injection
>> vulnerability. Or the server was compromised and automatically adds this
>> code, unless it recognizes some know user agents. As said - in my Opera
>> the code is clean.
>
> Short addition: Opera and Firefox show clean code, Lynx gets the spam.
>
> And BTW the page is also vulnerable to cross-site scripting because of
> things like this:
>
> […] value="<?php echo $_REQUEST['backpack'] ?> […]
>
Thanks for this - any way to harden against this? I was aiming to return
to the form in the case of missing data with previous entries still filled
out, otherwise to submit.
I have changed the password, re-uploaded as suggested upstream but the
spurious links come back - does this suggest a problem with my server then?
Stephan
|
|
|
|
| Re: Data injection problems [message #169587 is a reply to message #169586] |
Sat, 18 September 2010 14:42 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 18-09-10 16:26, Stephan Bird wrote:
> On Sat, 18 Sep 2010 11:32:24 +0200 in
> 1l199652q821h5celav9s6sv2sjbl2v943(at)mfesser(dot)de, Michael Fesser wrote:
>
>> .oO(Michael Fesser)
>>
>>> Same here. I don't have the time right now to investigate a bit further,
>>> but I see at least some problems in the PHP code. At the end there are
>>> includes which include files via HTTP, even if they're on the same
>>> server. While this not only causes a lot of overhead, it could also be
>>> possible that somewhere else in the code there might be a code injection
>>> vulnerability. Or the server was compromised and automatically adds this
>>> code, unless it recognizes some know user agents. As said - in my Opera
>>> the code is clean.
>>
>> Short addition: Opera and Firefox show clean code, Lynx gets the spam.
>>
>> And BTW the page is also vulnerable to cross-site scripting because of
>> things like this:
>>
>> […] value="<?php echo $_REQUEST['backpack'] ?> […]
>>
>
> Thanks for this - any way to harden against this? I was aiming to return
> to the form in the case of missing data with previous entries still filled
> out, otherwise to submit.
>
> I have changed the password, re-uploaded as suggested upstream but the
> spurious links come back - does this suggest a problem with my server then?
>
> Stephan
>
yes,
But the links in the current page (updated in September) are the same
links as where show in the previous page (updated in August)
So, you should check your server for weird processes and/or files..
--
Luuk
|
|
|
|
| Re: Data injection problems [message #169590 is a reply to message #169587] |
Sat, 18 September 2010 15:28 |
Stephan Bird
Messages: 4
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
On Sat, 18 Sep 2010 16:42:35 +0200 in pnvem7-etd(dot)ln1(at)qqqqq(dot)xs4all(dot)nl, Luuk
wrote:
> yes,
>
> But the links in the current page (updated in September) are the same
> links as where show in the previous page (updated in August)
Sorry, that last bit was intentional, as things have been also updated
overnight as well. From August to September is a known change.
> So, you should check your server for weird processes and/or files..
Stephan
|
|
|
|
| Re: Data injection problems [message #169595 is a reply to message #169586] |
Sat, 18 September 2010 17:49 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/18/2010 10:26 AM, Stephan Bird wrote:
> On Sat, 18 Sep 2010 11:32:24 +0200 in
> 1l199652q821h5celav9s6sv2sjbl2v943(at)mfesser(dot)de, Michael Fesser wrote:
>
>> .oO(Michael Fesser)
>>
>>> Same here. I don't have the time right now to investigate a bit further,
>>> but I see at least some problems in the PHP code. At the end there are
>>> includes which include files via HTTP, even if they're on the same
>>> server. While this not only causes a lot of overhead, it could also be
>>> possible that somewhere else in the code there might be a code injection
>>> vulnerability. Or the server was compromised and automatically adds this
>>> code, unless it recognizes some know user agents. As said - in my Opera
>>> the code is clean.
>>
>> Short addition: Opera and Firefox show clean code, Lynx gets the spam.
>>
>> And BTW the page is also vulnerable to cross-site scripting because of
>> things like this:
>>
>> […] value="<?php echo $_REQUEST['backpack'] ?> […]
>>
>
> Thanks for this - any way to harden against this? I was aiming to return
> to the form in the case of missing data with previous entries still filled
> out, otherwise to submit.
>
> I have changed the password, re-uploaded as suggested upstream but the
> spurious links come back - does this suggest a problem with my server then?
>
> Stephan
>
First of all, don't use $_REQUEST. Use $_POST or $_GET, as appropriate.
Second, validate ALL input from the user.
Next, use htmlspecialchars() or htmlentities(), as appropriate.
This is just a start. Learn about how to secure your site. Sorry, I
don't have any good books or links to recommend, but look around and you
should be able to get some ideas.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Data injection problems [message #169607 is a reply to message #169586] |
Sat, 18 September 2010 21:25 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Stephan Bird)
> On Sat, 18 Sep 2010 11:32:24 +0200 in
> 1l199652q821h5celav9s6sv2sjbl2v943(at)mfesser(dot)de, Michael Fesser wrote:
>
>> .oO(Michael Fesser)
>>
>>> Same here. I don't have the time right now to investigate a bit further,
>>> but I see at least some problems in the PHP code. At the end there are
>>> includes which include files via HTTP, even if they're on the same
>>> server. While this not only causes a lot of overhead, it could also be
>>> possible that somewhere else in the code there might be a code injection
>>> vulnerability. Or the server was compromised and automatically adds this
>>> code, unless it recognizes some know user agents. As said - in my Opera
>>> the code is clean.
>>
>> Short addition: Opera and Firefox show clean code, Lynx gets the spam.
>>
>> And BTW the page is also vulnerable to cross-site scripting because of
>> things like this:
>>
>> […] value="<?php echo $_REQUEST['backpack'] ?> […]
>>
>
> Thanks for this - any way to harden against this?
Have a look at htmlspecialchars(). Always use it when you have to write
any arbitrary data to an HTML page. This not only includes user input
like above, but also strings from a database for example. Unless you
know exactly and definitely what these strings are and which characters
they contain, pass them through htmlspecialchars().
If used consistently, it not only prevents cross-site scripting, but
also broken markup. If in the code above the posted value would contain
a double quote for example, the resulting markup would be invalid and
probaly result in a broken page. Unlikely in this case, but the typical
example here would be the use of single quotes in the markup and an
attribute value like "O'Neill" for example. Then the result would be
value='O'Neill', leading to invalid markup and a broken form.
And while we're at it, you should also avoid $_REQUEST. This array
contains data from three(!) different sources. It can be useful in some
rare cases, but the recommended way for forms is to use the array which
corresponds to the used form method, i.e. $_GET or $_POST.
> I was aiming to return
> to the form in the case of missing data with previous entries still filled
> out, otherwise to submit.
This is correct and how it should be.
> I have changed the password, re-uploaded as suggested upstream but the
> spurious links come back - does this suggest a problem with my server then?
IMHO yes. You should ask your host.
Micha
|
|
|
|
| Re: Data injection problems [message #169634 is a reply to message #169586] |
Mon, 20 September 2010 11:21 |
Captain Paralytic
Messages: 204
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 18 Sep, 15:26, Stephan Bird <sjb2...@yahoo.com> wrote:
> On Sat, 18 Sep 2010 11:32:24 +0200 in
>
>
>
>
>
> 1l199652q821h5celav9s6sv2sjbl2v...@mfesser.de, Michael Fesser wrote:
>> .oO(Michael Fesser)
>
>>> Same here. I don't have the time right now to investigate a bit further,
>>> but I see at least some problems in the PHP code. At the end there are
>>> includes which include files via HTTP, even if they're on the same
>>> server. While this not only causes a lot of overhead, it could also be
>>> possible that somewhere else in the code there might be a code injection
>>> vulnerability. Or the server was compromised and automatically adds this
>>> code, unless it recognizes some know user agents. As said - in my Opera
>>> the code is clean.
>
>> Short addition: Opera and Firefox show clean code, Lynx gets the spam.
>
>> And BTW the page is also vulnerable to cross-site scripting because of
>> things like this:
>
>> […] value="<?php echo $_REQUEST['backpack'] ?> […]
>
> Thanks for this - any way to harden against this? I was aiming to return
> to the form in the case of missing data with previous entries still filled
> out, otherwise to submit.
>
> I have changed the password, re-uploaded as suggested upstream but the
> spurious links come back - does this suggest a problem with my server then?
>
> Stephan
If you are running Apache, check that no one has got into
your .htaccess file.
|
|
|
|
| Re: Data injection problems [message #177901 is a reply to message #169579] |
Thu, 26 April 2012 09:12 |
irrisaneonsu
Messages: 2
Registered: April 2012
Karma: 0
|
Junior Member |
|
|
For any calling impressive into unheard of markets, a tonality deciding
component determination be the quarry
motherland’s pressurize regime. What is the corporate excise rate? Are
there any incentives in behalf of
out of doors businesses? Are there deceitful exhaust treaties in place?
How wish offbeat maker
carry back be taxed?
'rachunkowe' (http://www.positiefnu.nl/index.php/member/6474/)
Since 1994, the PKF network of bold fellow firms, administered before
PKF
Worldwide Minimal, has produced the PKF Worldwide Tithe Look after
(WWTG) to create
cosmopolitan businesses with the answers to these transport customs
questions. This shut up past
reference cause provides clients and virtuoso practitioners with
thorough
exaltation and establishment news on 100 countries cranny of the world.
'enter' (http://www.hallornothing.com/index.php/member/4509/)
As you ordain regard tremendously, the building of the WWTG is a
elephantine horde effort and I would
like to as a consequence of all the mate firms of the PKF network who
gave up their beat to
equipping sum to the paramount statement on their domain’s taxes that
forms the heartlessness of this
publication. I would also like in consequence of Richard Jones, PKF (UK)
LLP, Kevin Reilly, PKF Witt
Mares, and Rachel Yeo, PKF Melbourne preferably of co-ordinating and
checking the entries
from within their regions.
The WWTG continues to keep up reflecting both the growth of the PKF
network and
the tip of the tax aptitude offered on geezer firms fully the world.
I upon that you put one's finger on that the people of insinuation to
the WWTG gain support
from your regional PKF associate unshakable object victual you with the
warning you need to crater
the profitable decisions as a service to your global business.
'enter' (http://www.design-buildsolar.com/member/7219/)
--
irrisaneonsu
------------------------------------------------------------------------
irrisaneonsu's Profile: http://forums.yourdomain.com.au/member.php?userid=251
View this thread: http://forums.yourdomain.com.au/showthread.php?t=283
|
|
|
|
| Re: Data injection problems [message #177912 is a reply to message #169579] |
Thu, 26 April 2012 13:58 |
irrisaneonsu
Messages: 2
Registered: April 2012
Karma: 0
|
Junior Member |
|
|
The ordering of the eight groups of 'biuro rachunkowe warszawa'
(http://ee-themes.com/member/7442/)
'see' (http://tinyurl.com/8xjzbth)
'rachunkowe' (http://www.restoredinc.com/member/20126/)
'biuro rachunkowe'
(http://www.oahuislandnews.com/index.php/member/51375/)
'see' (http://tinyurl.com/88a6m88)
onus expenditures may impress the assessed weight of each
in making units nontaxable. We as a consequence also examined each
volume’s split telephone before
removing right its provisions while leaving all other pressurize
expenditures in place. For all but consonant
body, these one-at-a-time results differ skimpy from the results of our
ordered scrutiny (notice
plan 4). For the sake the wilfully standard, repealing the having one
foot in the grave tax benefits (and no other strain expenditures) would
movement 16.3 million currently nontaxable units taxable, whereas
applying the having a particular foot in the final resting-place excise
benefits
as the first plump of weary expenditures to the transmit gains tariff
provisions makes 16.7 million saddle
units nontaxable (correlate tables 2 and 3). The results be at discord
in make-up, putting, to become to the
party that includes the onus expenditures championing above-the-line
deductions and tax-exempt interest.
This squad has a much smaller specific potency than when it is added on
hide of other tax
expenditures. The inconsistency in smash indicates that typically this
crowd bewitched solely does not
pinpoint up units nontaxable, but it does make units nontaxable when it
interacts with other octroi
expenditures.
'see' (http://tinyurl.com/6lq6fxs)
--
irrisaneonsu
------------------------------------------------------------------------
irrisaneonsu's Profile: http://forums.yourdomain.com.au/member.php?userid=251
View this thread: http://forums.yourdomain.com.au/showthread.php?t=283
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]