| Author |
Topic Search Topic Options
|
Phat
Senior Member
Joined: 23 February 2003
Status: Offline
Points: 386
|
Post Options
Thanks(0)
Quote Reply
Posted: 06 July 2005 at 3:57am |
True True, I did not even look. I just registered and gave it a try. No sms so just figured it did not work.
Tried hacking a few parts with no avail.
|
|
|
 |
Mart
Senior Member
Joined: 30 November 2002
Status: Offline
Points: 2304
|
Post Options
Thanks(0)
Quote Reply
Posted: 06 July 2005 at 4:50am |
|
If you really can't figure it out you could contact a web developer and
pay him to read over your source code looking for glitches
|
 |
the boss
Senior Member
Joined: 19 January 2003
Location: Saudi Arabia
Status: Offline
Points: 1727
|
Post Options
Thanks(0)
Quote Reply
Posted: 06 July 2005 at 7:47am |
well storing username and password in a cookie in MD5 hash encryption followed by salt attached to it.. pretty long isnt it..
instead have a field in the database which will store a temporary random value each time user logs in.. use this random unique value to tag the user by storing it in the cookie..u can define the cookie to expire in certain days so a re-login would be enforced...
somewhat the WWGF method... the random value is MD5 hash i belive and the salt for it is also stored in the database
|
|
|
 |
Gullanian
Senior Member
Joined: 04 January 2002
Location: England
Status: Offline
Points: 4373
|
Post Options
Thanks(0)
Quote Reply
Posted: 06 July 2005 at 7:57am |
|
I do that.
Basically, 3 fields in database. Username, password and salt.
Salt changes every time you login.
Password is an MD5 hash of the password + newsalt
Cookie stores username field and password field
To check they are logged in it selects a user record where username = cookie and password = cookie
Failsafe ? Or am I missing something obvious.
|
 |
dpyers
Senior Member
Joined: 12 May 2003
Status: Offline
Points: 3937
|
Post Options
Thanks(0)
Quote Reply
Posted: 06 July 2005 at 1:52pm |
|
Perhaps I'm misunderstanding the situation...
The way I understand it is that you had a valid user send thousands of
blank sms messages. The first question I would address is "how did they
send thousands of requests". The second question would be is "has the
user id who sent the requests been hacked".
IMHO, the only way you can send thousands of requests within a
specific time period is through either client or server scriptiing.
Limiting requests within a time period for a session and by ip, perhaps
also limiting the number of active sessions, should reduce your
exposure there.
One of the things I would be concerned with would be flaws in my own code. Analysis of the the data might reveal a clue...
Are you sure that all of the messages sent by the user were blank?
(e.g. Were they really blank or did they contain unprintable characters
for your character set? Was there a sequence - like 1 message with data
followed by 99 empty messages or 1 x 9999? Did the user ever send a
message with data? What was the data in that message?).
Who were the messages sent to? (e.g. Were they valid SMS users? Did it
look like a dictionary attack? Did they all use the same provider? Were they all to one user?)
I'd probably try to walk through the input-execute-output process - not
just the code. Tools like Visual Studio allow you to process the code a
line at a time examining things as you go, but you can do the same with
pencil and paper. You might also want to sanity check input and output
headers and/or explicitely rewrite them before sending anything out.
Do you delete cookies? What would happen if I had multiple cookies?
would I be logged in multiple times? Can I be loggined in multiple
times at once? Will sending a message from 1 login cause all logins to
send that message? What happens if I have cookies turned off - am I
explicitely rejected, or do I fall through to something? What happens if I delete the cookies while logged in?
Find out how your mail server handles failed deliverys. Does it retry x
times? Were there problems with it on that day? If all the messages
were sent to/through 1 sms provider did they have problems that day?
How do they handle failed delivery attempts?
For the future, you may want to do additional session/user logging that
gets turned on automatically when certain event thresholds are reached
- e.g. x number of - failed login attempts, failed messages, blank
messages, failed deliveries, etc.
Edited by dpyers - 06 July 2005 at 1:54pm
|
Lead me not into temptation... I know the short cut, follow me.
|
 |
Gullanian
Senior Member
Joined: 04 January 2002
Location: England
Status: Offline
Points: 4373
|
Post Options
Thanks(0)
Quote Reply
Posted: 06 July 2005 at 2:43pm |
|
Thanks Dpyers, I will go through my code.
My webhost said there were no large attacks on my site in my logs,
which is rather unusual. However there were IPs 'from the RIPE
and Asian Pacific networks that do not regulate their customers'.
Most likely the hacker knew his business and masked his IP.
I don't think it was a valid user unfortunatly, that would be easier to
look out. I think they figured a way to send the messages outside
the system somehow. I have a few ideas that I am going to
investigate.
Thanks again for your detailed help everyone!
|
 |
Mart
Senior Member
Joined: 30 November 2002
Status: Offline
Points: 2304
|
Post Options
Thanks(0)
Quote Reply
Posted: 07 July 2005 at 8:27am |
|
Guess your attack will be low priority now, after the terrorist attack today
|
 |
Gullanian
Senior Member
Joined: 04 January 2002
Location: England
Status: Offline
Points: 4373
|
Post Options
Thanks(0)
Quote Reply
Posted: 07 July 2005 at 12:48pm |
|
Yeah that stuffs pretty nasty, sad watching it on the news.
|
 |