Logging XSS Attempts

I was wondering if there was a way to log XSS attempts? Like if some tried to pass some tags in a form or in the the URL the script would log their IP.

Or if they even submit some characters the you know would be needed in a search for instance.

Could someone show me some ideas in PHP, i'm not looking for it to use it just want to see what that would look like. In my eyes this would help greatly with XSS.

thanks :D

The file/ip part is easy enough. Here's a regular expression to remove tags, I've never had much experience with filtering the stuff, so if someone has a better one use it.

edit: that sucked.

The second tag may not have to be there sometimes(like <h1> or <b>).

Functions with search arrays and preg_replace() are probably used.

Filter input and check input by filtered output.

Like, if in the end you converted characters to html entities, then check what you want with the encoded output.

So, if you find: &# 60; (without space) being submitted into an input, than flag it as a possible XSS attempt.

Example: For a simple login, add another logic check: markupif ($input == strstr($input, "&# 60;")) { then xss_flag=1; } ^^^again without the space inside

You could have a special log file be written to for such attempts. Kept outside of your web root directory and only ip logged.

<?php
if(htmlspecialchars($whatever) != $whatever)
{
$file=fopen("/home/username/xssLog.txt","a");
fwrite($file,$_SERVER['REMOTE_ADDR']." - ".$whatever."\n");
fclose($file);
}
?>

That's what I would use. It's simple, but it will log every XSS attempt unless they are using a different encoding like UTF-7 or whatever.

Wait, if I followed that right. Only if they break out of htmlspecialchars, that will be logged. Add to that, the thing that broke out of the htmlspecialchars is being written to a text file?

Edit: Or were you not planning on filtering $whatever at all?

nights_shadow wrote: Wait, if I followed that right. Only if they break out of htmlspecialchars, that will be logged. Add to that, the thing that broke out of the htmlspecialchars is being written to a text file?

Edit: Or were you not planning on filtering $whatever at all?

If they break out of htmlspecialchars they will be logged, if they didn't there's no need to filter it. If they did, you can just add to that part to do whatever you want to with $whatever as if it didn't get logged, just have it htmlspecialchars'd.

The script just looked like it was asking to be XSS'ed as it didn't apply a filter before the checking of an attempt was started. Not only that, but logging unfiltered input into that file doesn't seem right either. Especially if there's an LFI that could break out and access any file on host.

Edit: And if the script was applied after a filter was set, than only working XSS attempts would be logged, not just attempted ones.

I bet a simple error log which recorded the input of what caused the error would capture most XSS

EDIT: Stupid me… I was thinkin SQL injection… never mind me.

nights_shadow wrote: The script just looked like it was asking to be XSS'ed as it didn't apply a filter before the checking of an attempt was started. Not only that, but logging unfiltered input into that file doesn't seem right either. Especially if there's an LFI that could break out and access any file on host.

Edit: And if the script was applied after a filter was set, than only working XSS attempts would be logged, not just attempted ones.

That's why you use htmlspecialchars() when you use the script if an XSS was attempted. The file it logs to is a .txt and it's on a different directory than the web root so it can't be exploited. The only way it could be exploited was if there was some vulnerability in fwrite() in which case, no matter what, it could be exploited. It can't break out of the file that it's supposed to log with because you aren't taking any input from the user. If it didn't get logged, it won't need to be htmlspecialchars()'d because it wouldn't change anything. It checks if an attempt was started by checking if the string doesn't match that string htmlspecialchars()'d. Please, at least try to understand the script before telling me it is XSS'able and there is an LFI vulnerability. If you want you can use filter_var() instead of htmlspecialchars(), would that make it safer? Absolutely not, but if it makes you feel better just replace htmlspecialchars() with filter_var and your preferred filter. If it is exploitable, please, tell me how you could exploit it and I'll fix that.

hacker2k wrote: [quote]nights_shadow wrote: The script just looked like it was asking to be XSS'ed as it didn't apply a filter before the checking of an attempt was started. Not only that, but logging unfiltered input into that file doesn't seem right either. Especially if there's an LFI that could break out and access any file on host.

Edit: And if the script was applied after a filter was set, than only working XSS attempts would be logged, not just attempted ones.

That's why you use htmlspecialchars() when you use the script if an XSS was attempted. The file it logs to is a .txt and it's on a different directory than the web root so it can't be exploited. The only way it could be exploited was if there was some vulnerability in fwrite() in which case, no matter what, it could be exploited. It can't break out of the file that it's supposed to log with because you aren't taking any input from the user. If it didn't get logged, it won't need to be htmlspecialchars()'d because it wouldn't change anything. It checks if an attempt was started by checking if the string doesn't match that string htmlspecialchars()'d. Please, at least try to understand the script before telling me it is XSS'able and there is an LFI vulnerability. If you want you can use filter_var() instead of htmlspecialchars(), would that make it safer? Absolutely not, but if it makes you feel better just replace htmlspecialchars() with filter_var and your preferred filter. If it is exploitable, please, tell me how you could exploit it and I'll fix that.[/quote]

lol, I didn't say your script had an LFI hole or XSS hole in it. I said that if there was an LFI vuln that could get out of domain restriction, $whatever could be used to leverage a shell. I'm asking, where are you putting this in relation to the user's input.

Case 1.) Before input gets filtered. If this is the case, the script would work, but you are playing around with unfiltered input ($whatever). This being where that potential LFI mentioned above would take effect.

Case 2.) After input gets filtered. This script would do jack shit. If this were the case, it wouldn't even log an XSS attempt because that XSS attempt would be htmlspecialchars($Input);. If it were a successful XSS, they managed to bypass htmlspecialchars(); to issue the XSS, so checking it wouldn't make sense.

Case 3.) User isn't going to filter input. Then, the script is just going to be used to test for people trying to attempt an XSS on you and log their information.

Case 1 is what it would do. I probably should have added into the script $whatever=htmlspecialchars($whatever); if $htmlspecialchars($whatever) != $whatever, but I scripted it in like 2 seconds so I didn't do everything that it should probably do. I see what you are saying about the LFI. Lol, I thought you meant like my code had an LFI vulnerability in it. Anyway, I understand now.

hacker2k wrote: Case 1 is what it would do. I probably should have added into the script $whatever=htmlspecialchars($whatever); if $htmlspecialchars($whatever) != $whatever, but I scripted it in like 2 seconds so I didn't do everything that it should probably do. I see what you are saying about the LFI. Lol, I thought you meant like my code had an LFI vulnerability in it. Anyway, I understand now.

lol, it's all good. I know where you were coming from. I just always think of the golden rule of secure programming, all user input should be considered as evil. It's a paranoid person thing.

nights_shadow wrote: [quote]hacker2k wrote: Case 1 is what it would do. I probably should have added into the script $whatever=htmlspecialchars($whatever); if $htmlspecialchars($whatever) != $whatever, but I scripted it in like 2 seconds so I didn't do everything that it should probably do. I see what you are saying about the LFI. Lol, I thought you meant like my code had an LFI vulnerability in it. Anyway, I understand now.

lol, it's all good. I know where you were coming from. I just always think of the golden rule of secure programming, all user input should be considered as evil. It's a paranoid person thing. [/quote]

Yeah, but you can only do so much to protect against attacks short of creating your own filter function with all of the known attack methods and ways to get around filters being blocked.