Slides from my shart talk about web server logs at the Digital Forensics Panel at the LawTech Europe Congress 2013, Prague, Czech Republic.
Shows you why you should be writing and reading logs, before it's too late.
1. Poor Man's Digital Forensics
Michal Špaček
Lead Web Developer
Slevomat.cz
www.michalspacek.cz @spazef0rze
2. Web Developers
http://example.com/products
I'm a web developer. I've been a web developer since, like, 2000. Web developers, you know, build web applications and web
applications run on the Internet and are using addresses just like this one above.
www.michalspacek.cz
@spazef0rze
3. So Web Developers
http://example.com/product?id=123
The better of us they also build web applications with addresses looking like this one. Such web application displays a lot of
useful details about a product or whatever info the developer of the application wants it to display.
www.michalspacek.cz
@spazef0rze
4. Wow, Web Developers
http://example.com/product?
id='+UNION+SELECT+1,2,3,4+#
SQL Injection Attack
The best of us, web developers, they build applications which display a lot of useful details and also whatever the bad guy
wants the application to display. This is called the SQL Injection Attack and it is responsible for some major information leaks
in last few years and is caused by the developer not properly handling user input. It is pretty common, unfortunately.
www.michalspacek.cz
@spazef0rze
6. All the Internet
WEB SERVERS
are writing access
LOGS!
Yes! Exactly. Whenever there's a request coming from a browser no matter what information ends up being sent back to it, the
requested address is written down to the server access log. So later you can see what your users are looking for, if needed.
www.michalspacek.cz
@spazef0rze
7. All the Internet
YOUR WEB APPLICATION
should be writing application
LOGS!
Just like the web server your application can also write logfiles. These files should contain more information and debugging
data because your application knows much more about the request than the server. It knows a lot about a user making the
request, what they want to buy and what was the result of charging their payment instrument.
www.michalspacek.cz
@spazef0rze
8. Many Logs
●
Disk s p a c e
●
Logger performance
●
Somebody has to read logs
Of course, logging is not easy. It's hard because logs take space and once your log files are too big there's no more room for
other data on the server and the server stops serving requests. The server has to perform well because it simply has more things
to do. Your hard drives need to perform well too. And the hardest part about logging is that somebody has to read the logs.
www.michalspacek.cz
@spazef0rze
9. Be a Digital Forensics Guy
Search the logs for
SELECT
BUT! If you have logs you can be a digital forensics guy, too! No, not the pro one, but good enough to detect a breach or data
leak. Just search the logs for some keywords and while you may get some false positives, you may also spot something.
Remember the SQL Injection Attack example? But please, don't modify the logs, the pros need them in their original state.
www.michalspacek.cz
@spazef0rze
10. Michal Špaček says
Write logs
Read logs
Before it's too late
Here's my advice. Write the logs. Read them as well. A lot of companies don't know they had their data leaked until they read it
on TechCrunch or Slashdot. That is well too late. Do something so that you're the first one to know that something went wrong.
The second one, actually. The first one is always the guy making it away with your data.
www.michalspacek.cz
@spazef0rze