Tag Info

New answers tagged

2

I think RFC 2616 is quite clear: 10.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the ...


9

In order to make C code "safe", even against a malicious developer, then you have to fix the core issues of C, which have all been repeatedly exploited for arbitrary code execution (exactly what you want to avoid): Weak types. In C, you can take a bunch of bytes, and interpret them as a pointer, an integer, or whatever. All it takes is a cast. As long as ...


3

Safer than not using a parser in that it will stop casual attackers, but not as safe as using a sandboxed scripting language. The big problem you'll run into is that some fairly low-level features of the C language, such as pointer arithmetic, can be used in nefarious ways. For example, you might forbid the use of open(), but a plugin could find a point in ...


1

Use-after-free attacks require the attacker to be able to allocate some memory reliably on heap. Say I have an object that takes 16 bytes, and happens to be allocated in memory to 0xb00000004 (completely made up numbers here). I delete this object and the memory is returned to the heap. Now I request another heap allocation for 16 bytes (a string for ...


1

The address in your environment may have changed because the environment is different. You could look at the coredump to find out the correct address to use ( you don't have to use a nop sled then :) )



Top 50 recent answers are included