Jump to content

Recommended Posts

  • Replies 53
  • Created
  • Last Reply

Top Posters In This Topic

if (!empty($_POST)){

array_map("strip_tags", "$_POST");

array_map("addslashes", "$_POST");

array_map("mysql_real_escape_string", "$_POST");

}

 

if (!empty($_GET)){

array_map("strip_tags", "$_GET");

array_map("addslashes", "$_GET");

array_map("mysql_real_escape_string", "$_GET");

}

 

I built this using Firefox and have no desire to make this 100% compatible with IE. I consider IE a plague that preys on the ignorant, therefore I will leave it to one of those to make it compatible.

 

 

Aggreed.  ^^

 

 

Im using firefox now, i use it all the time  :D

 

 

 

 

 

And it is really nice site  :)

 

 

I like the GUI  ;)

New update, I should have taken care of most of the password autocomplete stuff. Still looking for a good method to process/display form data.

 

I don't have access to how my server performs, I don't think. ??? I am leasing the resources from someone.

Tips:

Session IDs in URL (and hijacking) - if you’re using session IDs in the URL (as opposed to a session cookie), make sure offsite links do not contain the session ID (or the remote site will be able to hijack) - PHP should take care of this. Also your visitors may give away the session ID in the referrer field - ideally pass off site links through a redirect page, to elimate the referrer (although, unfortunately, some browsers keep the last 3 pages viewed I believe - unsure of facts).

 

Ideally, don’t pass session ids in the URL - require users to accept a cookie if they need to “log in”.

Session Fixation (pre-hijacking) (see http://www.acros.si/papers/session_fixation.pdf).

 

If you assign a session to a visitor to your site, before they are logged in (for example for clickpath analysis), make sure that you assign them a new session id when they do login, so that if someone pre-generated the initial session id for them, they won’t get the new ID.

 

For PHP 4.2.0+, see session_regenerate_id() (in particular the user submitted comments). For PHP < 4.2.0, you'll have to destroy the session and re-create it when the user logs in, carrying any stored data between the two. The session_id() function may also be useful (haven’t explored it in this context myself).

and the advice was valid look at this:

 

 

Vulnerability description

This script is vulnerable to PHPSESSID session fixation attacks.

 

By injecting a custom PHPSESSID is possible to alter the PHP session cookie. Attackers will normally manipulate cookie values to fraudulently authenticate themselves on a web site.

This vulnerability affects /Tickets.  and/tickets/admin

How to fix this vulnerability

Set session.use_only_cookies = 1 from php.ini. This option enables administrators to make their users invulnerable to attacks which involve passing session ids in URLs; defaults to 0.

 

 

 

 

Vulnerability description

The description for this alert is contributed by the GHDB community, it may contain inappropriate language.

 

Category : Files containing juicy info

 

This is a very basic string found on directory listing pages which show the version of the Apache web server. Hackers can use this information to find vulnerable targets without querying the servers.

This vulnerability affects /Tickets/assistwindows.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.